django-treebeard
Postgres ltree Support
Is there a plan to support postgres ltree? It has inbuilt optimisations to handle materialised paths. It would be great if we can make use of it to make the MP implementation more powerful.
That would be great. Over the years I've started trying to add support but some other project always comes up and I never get very far.
I just finished implementing treebeard into a complex saas product I am working on, that maintains trees for several parts of the application. It's heavily integrated and is working well, and adds tremendous value and functionality to the app. I came here to see if there were any recent updates to the package(thanks everyone for your work!) and saw this comment about pg's ltree. I was not familiar with it and started poking around and came across an example in github (https://github.com/peopledoc/django-ltree-demo) that demonstrates postgres' ltree with a simple custom django field that has a foreign key to self, and some postgres triggers to update the path field in ltree.
The example seems remarkably simple, uses ltree SQL to get ancestors/descendants and looks like it would very robust. It's effectively the MP implementation of treebeard with a variant of the path field, but with the db triggers doing all the path 'updating'. And, since it uses the ltree path of whatever value you wanted, you could just use the object's slug or pk or whatever custom value you wanted to in the path to sort by. Moving nodes around in forms and what not using treebeard was tricky to set up and I corrupted many a test tree learning how it works.
I recognize you limit yourself to using postgres (which doesn't matter to me) and lose some of the handy API (which could readily be reproduced with the pg ltree functionality), but am I missing something here? Or is it just that ltree didn't exist to support django's tree needs when this package was originally created? This treebeard package is utterly fantastic and adds so much to my app, but I am struggling to find a reason not to further investigate using (at least what appears to be) simpler postgres native ltree.
If ltree functionality was added to treebeard, how would that be done, or how would it look? Would the dB triggers be used to handle updating the path, or would that be done outside the db by python? Or would just the API converted to use the ltree SQL tools?
Thanks for any thoughts.
This is what I had been hoping for, for awhile now. I'm going to take a look at that demo project and see how difficult it would be to add support to treebeard. The nice thing about treebeard is that it's a popular project, so other projects would benefit from an LTree implementation (I think Django CMS uses it for storing page hierarchy).
I used that demo project as a basis to replace one of the treebeard MP trees in my project and it works flawlessly. I put the SQL directly into a migration file in the respective app and installed the ltree extension on postgres manually.
The tree path can be made up of nearly whatever values you want (I used a slugified value based on user preferences for their sort order field). You don't need to do anything fancy in your model forms or save methods and just update the parent or set to none to move nodes within and in/out of trees. Nor do you have to worry about gaps in the tree, or choosing a sort order, path length or alphabet set and not being able to readily change it.
It's so simple there isn't really a need for a package if this is the route you want to go. This could certainly be a fantastic addition as a new type of tree to treebeard for all the packages that use it as a dependency.
I am definitively interested in this, and will probably work on it before #122
