DeletedList not cleaned up.

rxelizondo posted on Thursday, January 14, 2010

Hello,

I was experimenting a little with collection items when I ran into the following scenario:

1. Fetch root object.
2. Add child object “X” to the root object collection.
3. Remove child object “X” from the root object collection.

At this point I would expect for the DeletedList to be empty but it still contains the “X” object and for the looks of it, this object will never go away.

This works appropriately.

1. Fetch root object.
2. BeginEdit on root object.
3. Add child object “X” to the root object collection.
4. Remove child object “X” from the root object collection.
5. ApplyEdit on root object.

This will clean up the DeleteList as I would expect.

Personally, I think that for the first example, the CSLA should realize that the object is new and that edit level is zero and should just nuke that object “X” straight away and not put it into the DeleteList.

The other option would be for the CSLA to throw an exception when adding a new child when edit level is equal to zero..... now, I can almost smell the response to that, it will go something like “This behavior is by design” followed by something like “This allows something like ASP to be more efficient” or something.

I am still experimenting with this so I would appreciate if someone could tell me if I am missing something. I tried to follow the code but it looks somewhat complex and I don’t necessarily want to dive into this right now…. at least not for this list type, is not worth the time for me, I probably would for the observable one.

Thanks

tmg4340 replied on Thursday, January 14, 2010

The DeletedList collection primarily exists to support undo functionality.  That's why the second set of steps is what's giving you the behavior you expect.  So "nuking the object straight away" would break undo, since you could no longer get that object back if the user pressed "Cancel".

HTH

- Scott

rxelizondo replied on Thursday, January 14, 2010

Thanks Scott,

The thing is that we are in the *same* edit level when we do add/remove so to me it makes no sense to put a brand *new* object into the deleted collection to in such scenario.

When we add and remove an object while in the same edit level, a CancelEdit() as well as ApplyEdit() operation would end up removing the object from the DeletedList so what is the point for putting it there in the first place?

tmg4340 replied on Thursday, January 14, 2010

If you think beyond a simple OK/Cancel scenario, what if you have a user who entered the new child record and then deleted it by accident?  If the application provides an undo facility on the data-entry screen, then they can get their new record back, complete with the values they entered.

It is admittedly something of an edge case.  But it's also the "more consistent" method of handling objects - no special coding required for new objects.

HTH

- Scott

rxelizondo replied on Friday, January 15, 2010

Not sure I am following you, are you describing the following scenario?

1. Fetch root object.
2. BeginEdit on root object.
3. Add child object “X” to the root object collection.
5. CancelEdit on root object.

Because if you are describing this scenario, then the “X” object will simply go away.

I am pretty sure this is not what you meant though. Could you please be little bit more specific? I think I am just missing something very simple.

Just to be sure, we are still talking about adding and then removing at the same edit level right?

tmg4340 replied on Friday, January 15, 2010

User has a form where they can enter several child objects at once - basically, a single form to manage the entire collection as a group, if you will.

1. User opens form.

2. User creates a new child item and adds it to the list.

3. User accidentally deletes the newly-created child from the list.

4. User utters favorite expletive, then clicks the "Undo" button/menu option/toolbar button.

5. User is happy, as the newly-created child object they deleted is back, complete with all the information they already entered.

6. User clicks "OK" to save the whole shebang and exit the form.

This is not a simple cancel/apply operation, because this isn't a block-level operation.

After checking things over, this is admittedly not a scenario that CSLA directly supports.  But it is possible to make this work, at least on a limited basis, as I've done it before.  If you directly dumped the child object, it would be impossible.  Based on that, if it was decided to simply dump new children instead of moving them to the deleted list, I likely don't have a good case to keep the old functionality around.

HTH

- Scott