Deep Hierarchy Child Delete Issue

Deep Hierarchy Child Delete Issue

Old forum URL:

rxelizondo posted on Thursday, February 02, 2012


Given a hierarchy such as “Parent -> Children -> Child -> Grandchildren -> Grandchild”. If you delete a "Child" object using its parent collection “Delete()” method as in: “theParent.Children.Delete(theChild)” and then save the parent. The delete data portal will only be called on the "Child" object but on the "Grandchild".

It’s been a while but I think I remember reading on some old post that this is the way is supposed to work but I would like to make sure. If you ask me I would say that all delete data portals on all the children on all lower levels of the hierarchy should be fired but I have a feeling that is not the way it works and I would venture to say is all in the name of performance.

Can someone confirm if this is a bug or a feature?


RockfordLhotka replied on Thursday, February 02, 2012

The data portal doesn't cascade any calls to child objects unless you write code in the parent to cause that to occur.

If you want to cascade the delete calls you could do so, but normally that isn't the way it is done. As you say, for performance. Normally the object that's deleted, if a parent, deletes all data below it in the database structure, and then just sets all its child references to null to effectively discard the now-unnecessary objects from the object graph.

Occassionally someone has the requirement to keep the object graph intact, but have all those now-deleted child objects marked as new. That's pretty rare (I've only seen it one or two times ever), and in that case you do need to cascade the delete calls through all the child objects.

rxelizondo replied on Friday, February 03, 2012


Thanks Rocky,

I guess my question is why can’t the CSLA automatically cascaded the deletes anyway and let the developer decide whether he or she wants to handle all children deletes on the parent object (as you suggest) or if he or she prefers to call “FieldManager.UpdateChildren()” on the parent and let each child delete itself (as I suggest)?

I personally prefer to let each child delete itself, I find that to be a more encapsulated and consistent approach. Also in our case (and I would expect this to be the same for most apps) the deletes account for probably around 1% or less of the data portal transactions so we don’t need that extra performance gain for such low volume. Also, the reality is that even if the children delete themselves (unless you have thousands of children) the children deletes occurs so incredible fast that the performance gains are just about 100% irrelevant.

I realize that I can cascade the deletes manually (that’s what I am doing now) I just think that this type of work is best suited for the CSLA.

Am I missing something?



RockfordLhotka replied on Friday, February 03, 2012

I think it could cascade automatically, though that's not as easy as it might seem at first. Right now no child calls cascade automatically.

Cascading automatically is easy enough in one sense, but in practice there are dependencies between sibling objects in some cases. So really making this work requires adding the ability for you to describe the data dependencies between all the objects in the graph, and then having this new CSLA functionality be smart enough to walk the graph in the correct order based on those dependencies.

That gets dangerously close to ORM behaviors, and I'm really not interested in CSLA becoming an ORM.

Copyright (c) Marimer LLC