Project

General

Profile

Actions

Bug #2053

closed

Bug with ptr::remove() during stale object check

Added by Saif Rehman almost 11 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
-
Start date:
07/21/2013
Due date:
% Done:

0%

Estimated time:

Description

After the delete statement is executed, affected rows are checked weather there was a row deleted or not. However when there is a OnDeleteCascade in the relation and deleting a row causes other rows to be deleted too, while deleting multiple rows a Stale Object exception may be thrown.

Although the object is stale, however, there is no way to reread() to avoid the stale object exception. Either the stale object check method should be redesigned or there should be a check and sorting due to the relation before carrying out the deletion.

Actions #1

Updated by Koen Deforche almost 11 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche
  • Target version set to 3.3.1

Hey,

I'm not sure if I understand this right, but we should simply change the check modifiedCount != 1 to modifiedCount == 0 ?

I haven't tested this on all platforms, but I am not sure that affected row count will consistently also return how many objects were deleted by cascaded deletes?

Regards,

koen

Actions #2

Updated by Saif Rehman almost 11 years ago

I wasn't clear before sorry. When deleting multiple rows, if a row with many referenced rows(many side) is deleted, then those referenced rows gets deleted before the transaction is committed due to OnDeleteCascade. After deleting this many side row, if a one side row is also included in that transaction then affectedRows will be 0. Due to this a stale object exception is thrown.

Although it is correct that those rows, after the many side row have been deleted, ARE stale however it cannot be reread because it is no longer in the database.

Due to this the programmer either has to change the constraint to OnDeleteSetNull or a has to check before deleting weather any of those one side rows are included in the transaction and manually remove it.

Actions #3

Updated by Koen Deforche over 10 years ago

Hey,

But if the transaction is not committed, and rolled back (because of the exception), then these other rows are not actually deleted?

Regards,

koen

Actions #4

Updated by Saif Rehman over 10 years ago

If the transaction rolls back. None of the rows are deleted since they're all in one transaction.

What I'm trying is I let the user select multiple rows from a WTreeView(its a tree table). When the delete button signal is emitted by the user. The program iterates over the selected indexes and deletes the Wt::Dbo::ptr that I store in the tree model data(UserRole). If the user selects a parent item and a some of it's children items. The stale object exception will be thrown. Do you have any idea what I can do to fix this?

Actions #5

Updated by Koen Deforche over 10 years ago

Hey,

You could reverse iterate the index set, this will first visit children before the parent.

Koen

Actions #6

Updated by Saif Rehman over 10 years ago

Thanks but still this may be an issue in other cases

Actions #7

Updated by Koen Deforche over 10 years ago

Hey Saif,

I don't think that Dbo does (or can do) anything else here, compared to other ORM's? The cascading logic happens at the database level and Wt does not have visibility in it.

Regards,

koen

Actions #8

Updated by Koen Deforche over 10 years ago

  • Status changed from Feedback to Closed
  • Target version deleted (3.3.1)
Actions

Also available in: Atom PDF