| 11/25/2006 8:21:56 AM |
I have an entity (Calculation) with a OneToMany relationship to another entity (Record). This relationship is lazy-loaded, because there could be many records. I've found that when I mark a Calculation for deletion and persist the changes to the object graph, all the Records are loaded before the deletes are executed. This looks like a bug to me. If you search for "subChildren" in Instance.cs, you'll see where the load is triggered. It goes through all the objects in the list, even though there are no relationships in the Record entity that a delete should cascade through to. WORM obviously knows this without loading any objects, and if the IsLoaded is false it doesn't seem to make any sense to go through all the objects looking for objects with Inserted or Unknown states. Perhaps this should be modified to skip the enumeration if IsLoaded is false and subChildren is false? |
| 6/8/2007 9:51:06 PM |
Hi, there - I think I have just run into this, too. When a lazy-load child list is not yet loaded and you try to delete the parent, the child list gets loaded. This is normally not a problem, except when the child entities have lazy-loaded child lists themselves (grandchildren).
Consider this graph of classes A, B and C
A:1 (parent)
--B:1 (child of A:1)
----C:1 (child of B:1)
--B:2 (child of A:1)
----C:2 (child of B:2)
If A1's list of B is loaded, and both of B's lists of C are loaded, worm can successfully delete A:1 by:
- Delete all C where parent is B:1
- Delete all C where parent is B:2
- Delete all B where parent is A:1
- Delete A:1
BUT, if A:1's list of B is not yet loaded and worm tries to delete A:1, this happens:
- Load all B where parent is A:1
- Load all C where parent is B:1
- Delete all C where parent is B:1
- Load all C where parent is B:2.........CRASH!
Step 4 causes a timeout (in SQL Server anyway) because the C table is locked by the delete in step 3.
This is easy to see by running a trace and watching. Can anyone else confirm this behavior?
Thanks, David Martines |