Bug in DeepSave with delete of child collections

There seem to be a bug in the DeepSave method, when deleting a child collection:

Generated code:

// Save Root Entity through Provider

this.Save(transactionManager, entity);

//used to hold DeepSave method delegates and fire after all the local children have been saved.

Dictionary<Delegate, object> deepHandles = new Dictionary<Delegate, object>();

First save the entity, then save the children that refer to the entity.

When you delete however, this should be done the opposite way (first delete the children, then the entity).

So, if DeepSave is meant to cover deleting of child collections, this should be changed.

Using MarkToDelete() to specify the entity to delete

Anyone that has done DeepSave with deletes?

Am I the only one with problems?

Thanks

I'm running into the same problem.

Is there a solution/workaround for this?

Thanks.

 I'm running across the same issue myself.  I even tried to be slick about it, and delete all the child entities, by calling the Delete() on the child entity's service, BEFORE calling save on the parent entity, only to get a Concurrency exception during the parent's DeepSave() as it tries to delete all the child entities as well.

Does anyone have any ideas about how to solve this?

Best regards

 GRAW
 

 I've solved it in my local rev.  Should be posting soon.

 Robert,

I hate to be a pest, but when do u think u'll be able to post this fix?

Almost done, it's a fairly large post on my part, lots of updates.  Will be within an hour or so. 

since you are in in deep save I will post this here rather than on a separate thread.. .its a slightly different issue but within Deepsave.

 I have two tables where tableOne  has 2 foreign keys  to table 2. 

Company Table
CompanyId
DefaultPricingScheme1
DefaultPricingScheme2

Pricing Table
PricingId

(table/fields have been changed to protect the innocent)

When I run the NUnit tests generated by net tiers I get an error in DeepLoad, but it is the DeepSave that is kicking the error.  It happens because the Pricing has two List<Company> that are generated (1 for scheme1 and one for scheme2) , and the deephandles are being added by the ListType... so on the scheme2 list, there is already a deephandle with the same name in the deephandles collection.

Hope this all makes sense.  I am disabling that Nunit Test until i hear about a resolution.

I thought i had already fixed that a long time ago.  Are you using something recent?  

k, it's posted.
SVN 597
give this a whirl and see if it meets your needs.

i was using 596.  I will try your 597 soon.

and your right, it had been fixed, now its back!

Still getting the same issue with DeepSave in Rev 606.