Delete / Insert order - Possible bug?

detritus posted on Tuesday, January 20, 2009

Hello all,

I've a BO with an items (child) collection of used products in that BO. After fetching it from db if I delete, say ProductA, from the items and add it again or do this for many products in the list and save to to the database most of the times I get primary key violation (from the child table).

The reason for the violation is Csla does not saves "deleted" items first and if any of the "new" items contains same product within previously deleted items (but not yet sent to the db) key violation occurs. I don't know if this is a bug or not.

I know there is a _deletedList around, tought about re-using deleted items from that list in case user selects the same product again but could not find any documented way to do it. In ProjectTracker I see ContainsDeleted method but not used in anywhere. Is there any method like UnMarkDeleted to let Csla know we will not delete this child item or any proper way to force Csla to save deleted items first?

Thanks in advance,

RockfordLhotka replied on Tuesday, January 20, 2009

What version of CSLA?

In 3.6 the Child_Update() method does update the deleted items first (so they can delete themselves), and then does any insert/update operations.

Prior to 3.6 you must write your own update method in your collection (either DataPortal_Update(), or Update()), and it is your responsibilty to do any deletes first. This is discussed in the Expert 2005 Business Objects book, with code examples on how to do it.

detritus replied on Tuesday, January 20, 2009

Well, I'm using code from the SVN repository directly, so it should be the latest since I updated it a few days ago. Let me debug the method you mentioned and see if I'm doing something wrong.

Thanks for the "really" fast response by the way.

detritus replied on Tuesday, January 20, 2009

Sorry, it's my mistake. Using template generated code failed me in this case (in templates (linq) inserts submitted immediately usually for root to get its identifier, I did the same thing for the child and I did cause child inserts to be submitted before update & delete which do not call SubmitChanges).

Thanks again.

detritus replied on Tuesday, January 20, 2009

More on this for future reference,

I think linq2sql also got confused in this scenario (deleting and adding same key'ed items without SubmitChanges call except in root). I got timestamp field in objects and in this case linq2sql thinks I'm changing timestamp column manually and complains about server generated field. Actually both are different objects but from linq perspective they're same (same key in both, first to be deleted, later to be inserted/updated).

Probably calling SubmitChanges after each child delete will make sure linq change tracking to be consistent with my object structure.

Hope it helps for someone.