Hello all.

This works:

EntityChild child = new EntityChild (new Guid (stringKey));
((EntityParent)parent).ChildCollection.Add (child) ; // Add to databound collection
unitOfWork.AddForSave(child) ;
... 
AccessAdapter adapter = new AccessAdapter();
unitOfWork.Commit(adapter, true);
...
(Oops!  That entity was a mistake... so....)

EntityChild child = ((EntityParent)parent).ChildCollection  [grdChildren.ActiveRow.Index] as EntityChild; 
grdChildren.DeleteSelectedRows(false) ; // Disappears from grid
unitOfWork.AddForDelete(child) ;
... 
AccessAdapter adapter = new AccessAdapter();
unitOfWork.Commit(adapter, true);

No problem with that. However, this DOESN'T work...

EntityChild child = new EntityChild (new Guid (stringKey));
((EntityParent)parent).ChildCollection.Add (child) ; // Add to databound collection
unitOfWork.AddForSave(child) ;
...
(Oops!  That entity was a mistake... so....)

EntityChild child = ((EntityParent)parent).ChildCollection  [grdChildren.ActiveRow.Index] as EntityChild; 
grdChildren.DeleteSelectedRows(false) ; // Disappears from grid
unitOfWork.AddForDelete(child) ;
... 
AccessAdapter adapter = new AccessAdapter();
unitOfWork.Commit(adapter, true);

The only difference, as you can see, is that in the second code snippet, the UnitOfWork is not committed between the AddForSave(child) and the AddForDelete(child) calls.

As it turns on, in the second snippet, the EntityChild is added to the collection - even if I explicitly remove the child from the parentCollection.

In other words, once I use AddToSave(entity), there doesn't seem to be a way to undo it before the commit. No matter what I do, it WILL be saved on the next UnitOfWork.Commit call (even if its removed from the collection).

Once saved to the collection, THEN I can go back and delete it in the next UnitOfWork.Commit call.

Is this by design?

Thanks.

Jeff

AddForDelete only works on non-new entities. New entities are ignored by default. So you can't 'fix' a mistake in the UnitOfWork object handling using that method.

There are a couple of design flaws related to the UnitOfWork class, one being too less virtual methods and another being no control logic available to see what's inside the unitofwork to fix mistakes... these are addressed soon, but require some code overhaul so I can't provide a quick patch for you now.

A workaround for now can be to work with a collection for saving, for example parent.childcollection and add that for saving.

Thanks for the response, Frans.

I have some time on delivering my application, so I think I'll wait for your UnitOfWork fix instead of reworking my code. Plenty of other things to do in the meantime.

Any idea when the fix might be available?

Take care.

Jeff

Jeff wrote:

Thanks for the response, Frans.

I have some time on delivering my application, so I think I'll wait for your UnitOfWork fix instead of reworking my code. Plenty of other things to do in the meantime.

Any idea when the fix might be available?

Take care.

Jeff

I hope to be done by the end of february. (beta). We made some tough decisions this week as to which features would be added to this upgrade and which would be postponed till the update for april/may, so I have till end of february to implement it all, and then beta starts and you can try out the goods