Allow for more than one ancestor per node

[erchenstein]

Hello,

first thanks for making this project, it is definitely an enrichment for the django-ecosystem to have a closure-table implementation.
I have a question regarding allowing more than one parent/ancestor per node. A big advantage of closure table is, that it can save also structures that are de jure graphs but are in practice more like trees (a subtype of directed acyclic graphs). An example for that are administrative divisions where you have a main hierarchy of units like counties, provinces, states/regions etc. but some units can not only be part of the next higher unit in the hierarchy but also of units like electoral or court districts. For example in france, germany or belgium electoral, court and administrative districts are build out of municipalities but these units are not congruent in any case so that a municipality can have more than one district type as a parent district.
Therefore it might be beneficial for some users to allow for more than one ancestor per node in order to save such structures. The adjeceny list could be optional or only used to save the "main hierachy".

Regards

[TimurKady]

Hi erchenstein,

Thank you for your kind words and interest in the project! I truly appreciate your feedback.

Your request touches on hybrid hierarchies, where a tree structure behaves more like a directed acyclic graph (DAG), but still maintains a primary hierarchy.

Django Fast Treenode is built on a Closure Table, which inherently supports DAG-like structures. However, the current implementation is optimized for strict tree hierarchies, and allowing multiple parents per node would require modifications to TreeNode.

From a technical perspective, implementing this is feasible, but it would significantly impact functions like get_ancestors(), move_node(), and delete_node(), requiring careful adjustments. If there is strong demand for DAG support, I would consider adding it in version 5.x (Beyond Django ORM).

At this stage, I’d like to understand how many users would find this feature valuable. If I decide to move forward with it, I will definitely keep you updated. And of course, I’d greatly appreciate your participation in testing it!

Looking forward to your thoughts.

[TimurKady]

To allow multiple parents for a node:

• nothing changes in ClosureModel.
• in TreeNode, the ForeignKey restriction on one parent is removed, replacing it with ManyToManyField.
• an additional field primary_parent can be introduced to preserve the "main" hierarchy. And all other relationships will remain in ClosureTable.

But, as I said above, the main methods will have to be redefined and expanded.

Looking forward to your thoughts.