Got another request here for ya... would it be possible to have recursive deletion? Meaning, if I delete a parent node I would like all of it's children and their children and so forth deleted (only if they have no other living parent)? Only children that would normally be orphaned should be deleted.

Comments

javanaut’s picture

That's something that I had considered, but I think it would only work well for tree-like hierarchies. If there were any fogotton relationships that connected to the rest of the network, disaster would ensue, I'm sure. One thing that might be a practical compromise would be "delete me" checkbox next to each link in the query search results. Maybe there could be an "Action" associated with each query, such as "List", "View", "Delete", etc. With big networks, the possibility of making a big mistake grows quickly. Any steps between the delete button and the actual removal of content are good, especially if everything that's being deleted is at least listed out.

I could see it like this:

Run a query with action of "Delete"
Search results return a list of nodes with a prechecked checkbox next to each.
A Delete Confirmation button is at the bottom, and all checked nodes get deleted upon submission.

How this would work when deleting thousands of nodes at one time, I'm not sure. I would, however, want users to see everything that's going to be deleted prior to deleting it.

Aran Deltac’s picture

I could see a set of options like this being really helpful:

  • Only allow one-to-many relationships w/o loop-back references (tree structure).
    • Enable cascading deletes on tree structures.
      • Default to cascading deletes.
      • Display confirmation dialog.

Now, assuming the above options and associated features were implimented, what if I wanted one part of the system to work as a tree structure with cascading deletes but I wanted another section of my site to work much more open and freeform?

javanaut’s picture

Only allow one-to-many relationships w/o loop-back references

I think that alone would be quite difficult using the current configuration options. It would be easy enough to restrict relationships to 1-n (by only allowing parental ordinality to be "one" or "none"), but to do this differently for different parts of your site would be the challenge. Also, if the 1-n setting was enabled on an existing data set that contained m-n relations, what would/should the behavior be?

I can see the settings form needing it's own table pretty soon ;)

Aran Deltac’s picture

Ya, I know, I felt like a little kid asking Santa Claus for toys when describing those options.

Well, I tend think that one should always treat users as dumb and site administrators as smart. So, if a site already has m-n and then the admin changes the setting to already allow 1-n then that is their own problem. Your code shouldn't have to detect that the admin knows what they are doing or not, they should be smart enough to ahead of time re-structure the nodes as 1-n only and then turn the setting on.

Is there any way that the module could be broken in to 3 pieces?

  1. Core Functionality
  2. m-n Handling
  3. n-1 Handling

I don't know exactly how this could be accomplished, but from a totally detached viewpoint of a Perl programmer (me) this makes sense. I'm just now starting to play with writing modules in drupal. :)

Aran Deltac’s picture

Title: Cascading Delete » One-Parent Only?

How bout this - seems simple - have an option in the settings that is "Allow only one parent" then when viewing a node if the node already has a parent then the attach parent link is hidden. Same for a parent - when clicking the attach an existing child link it will only list those children that do not already have parents. Seems simple enough and it means you wouldn't have to enforce any extra checks because you are not saying "it has to be a tree", just that it can have only one parent.

javanaut’s picture

have an option in the settings that is "Allow only one parent" - already there :)

I still have problems with the "attach existing parent/child node" flow. There's going to have to be some way of listing out nodes that you want to add that won't pull the entire node table into the page. Before adding anymore "attach existing node" like functionality, I need to figure this out.

I'm going to take a break from new features for a while and focus on getting the existing ones more solid. The module's already getting kinda big (>1000 lines) and I haven't stopped adding new features yet. I think the "cascading delete" and "attach existing parent" features sound very useful, but I'm going to have to put them off for a little while to get the rest of this code in order. Don't stop suggesting new features as you think of them, though :)

Aran Deltac’s picture

I'll deffinately keep makeing suggestions as necessary. But, I must say, I've already been quite amazed by your response already. Right now I'm just happy that the module is at the point where I can use it in my situation. Anything beyond that is a bonus. Thanks for all the hard work!