Options for deleting children when parent deleted

There should be an option in the relativity configuration to delete children on node delete. I may get around to submitting a patch for this at some point, but hopefully someone will beat me to it. ;)

For now, I've been doing this:

      $types = <array-of-content-types-that-this-applies-to>;
      if (module_exists('relativity') and in_array($node->type, $types)) {

        // Look for children in the relativity table.
        $result = db_query(
          'SELECT nid FROM {relativity} WHERE parent_nid = %d', $node->nid);

        // Delete each one.
        while ($child = db_fetch_object($result)) {
          node_delete($child->nid);
        }
      }

It works quite well for me. If you've got problems with module weight, play around with the weight field in the system table, or just use the Module Weight module.

Yes, I forgot to mention that, the delete section of hook_nodeapi(). Glad I could help! ;)

Relativity only deals with relationships among nodes, so deleting children nodes is outside this module. The only way I see this feature going in the module is if someone writes and thoroughly tests (we're talking about deleting nodes here!) a patch which upon deleting a parent presents a list of children to delete (maybe with checkboxes) and asks the user if the children should be deleted as well. It's still problematic though, because these children might be parents of other nodes, etc.

I'm not sure I agree that this issue falls outside of the module's scope. It should be a design decision made by the site admins, just like setting up cascading deletes on a DB with references. There are situations where orphaning nodes will lead to an inconsistent site, and there should be some way of dealing with this. It shouldn't happen by default, but there should be a checkbox or some such thing that an admin can set.

This decision can't be left up to the user in all cases. If the site will become inconsistent, then there shouldn't be user choice. I do agree that in some situations this makes sense, however. Maybe an admin can allow/disallow this behaviour? That can be another checkbox, "Give users the option to not delete child nodes on a confirm page?".

And of course we can have a third checkbox. One that says something like, "Have cascading deletes when multiple inheritance is enabled?". This one should be off by default.

That's what I've been thinking. Does that make sense?

It sounds like darius agrees that it could be in scope but that the options for deletion obviously call up all relationships for the node and children or other related parents.

Colan, will you be working on this?

If so, it does not sound like the options you recommend will meet the need completely. Can you work on something along the lines of what darius is recommending?

I would try and integrate those ideas, but I won't be working on this, at least for a while. I'm just opining at this point. hook_nodeapi solved my immediate problem, and I've got other priorities right now. I would like to see the status of this issue changed from "won't fix" to "active" or "postpone" so it will encourage more discussion and allow for someone else to potentially start working on it. Would that be okay with everybody?

I would like to throw my hat into the ring and point out a few things, with respect to node deletion and heirarchies/relationships between nodes.

On the one hand, I concur, that a multi-relationship node, where the parent of a child is the child of a parent or the child of the parent node is also a parent to other nodes, can prove to complicate matters in relationship management. Though, much like a file folder heirarchy, should the root folder be deleted, any subsequent folders and files will be removed from the system and any symbolic links or references to these files will no longer be valid. Perhaps, since this module does in fact create a working relationship between nodes, acting much like my folder example, the management of those nodes falls into the scope of its controls. Thus, deletion or re-organization of nodes within a relationship should, in my opinion, reside squarely with this module.

For instance: a common heirarchy is a simple parent<->node relationship such as Artist<->CD. Should I decide to delete the Artist, all of the Artist's CDs should be deleted along with it. A more complex relationship, such as recipes, where a recipe has ingredients and ingredients are shared among many recipes would clearly violate this management caveate. Therefore, exceptions would exist for multi-heirarchies, but in both cases, deleting should reference the relativity between them and identify a need for extra controls. This example would also prove that a management tool is required to easily move all nodes that exist under one parent to another. Much like moving files from one folder to another.

Several projects I have worked have required we resolve this particular problem, one way or another. The usual route I have undertaken is by emulating the UI most users are familiar with: a folder-like control interaction. Should a user delete a node, a warning that the node along with all its children will be deleted and the process is not reversible is presented and requires confirmation. This minimizes the possibility of orphaned children. Yet, realizing the full scope of the controls, much like Darius suggests be implemented, would be the natural evolution of this module.

I vote for either a complimentary module that enables relativity node controls and management options or these same be built into the module as it exists.

I also vote for an OPTION for deleting the child-nodes when the parent is deleted. In a sense it won't be much different from the existing option "Enforce Parental Rules".

I hope this hasn't fallen off the radar.

I would like to see the option of deleting children in this module as well. It makes perfect sense as wilco pointed out that as this module makes the relationship upon node creation, it should own that relationship upon deletion as well.

Well it looks like this certainly has fallen off the radar...I never did understand why this was beyond the scope of the module. When you breakup with someone (end the relationship) they usually aren't still in love with nor you them. So in affect you both are deleted from the relationship. Or look at a book. When a book becomes unpublished from a bookstore, they don't stock the separate pages still. Or when you throw away a jar of marbles, the marbles are thrown away too because they are IN the jar.

To me this just seems like such a simple concept. All I personally ever wanted was a simple parent-child relationship. 1 parent, many children. Not parents with 5 children that are parents of 3 children or any of that. Basically all I wanted was the way comments work. all the comments under that node get deleted once the node gets deleted. My problem was that I needed to have different comment types (which is another thing that doesn't exist). I would love to put this functionality in myself, but I am just not good enough with PHP at the moment.

This patch doesn't provide a UI but allow other modules to act before the relationships are deleted.

You can implement a hook that does the job:

function yourmodule_relativity($op, $node) {
  if ($op == 'delete') {
    // find and delete children nodes...
  }
}

Reworked against DRUPAL-6--1

+1