Open dalito opened 1 year ago
Unfortunately it's not maintained anymore. I was looking into django-tree-queries a while ago and now I see it's linked from mppt project as well. Might be an option.
There are a few more packages that do the same thing as mppt.
And some Postgres only packages
Maybe start with - https://github.com/jokiefer/django-mptt2/ that @jokiefer maintains. "Based on the idea of the unmaintained django-mptt package i implemented this new code base to replace it." Seems like it would be a drop-in vs shifting to a different implementation / option.
I looked at the various tree-packages for django last year. This was not related to this issue but for another application. I found django-tree-queries most interesting (as @vittoriozamboni). It is from one of the ex-maintainers of django-mptt. He wrote an interesting blog about about his motivation.
But switching to django-mptt2 is probably the easiest step forward (I have not tried).
keep in mind, that djang-tree-queries has some disadvantages about django prefetching technics, cause it uses raw queries.
That's one reason why i need to start my own project with django-mptt2. An other reason was, that django-treebeard, which also implements a nested set, is that there are no thread safeativity.
If there is a package which solve boths, my mptt2 package is not needed. My mptt2 package is also only supported for django >= 4.2.
EDIT:
another hint: you can't set new Index object for mptt fields, cause _meta.get_field() does not provide mptt fields. This will raise an Error on model check. So long you use mptt, you can't fix it. See also the deprecated note of index_together ==> https://docs.djangoproject.com/en/4.1/ref/models/options/#index-together
# example index extension
indexes = [Index(fields=("tree_id", "lft", "rght"))]
So if someone uses this indexes, he can't migrate to django 4.1. In my pov, this is another point in selecting a new tree package. It shall support all the django default things such as prefetching, indexing etc. Otherwise the user can't optimize queries.
But this is only my opinion, which i want to tell about. I never used django-groups-manager
before but i'am interested to hear about it. We've all got the same Problem. Migrating vom mptt to a well maintained package.
I am conscious that relying on an unmaintained library is both a risk and a pain, but unfortunately I don't have the capacity at the moment to evaluate new core libraries and test them for a successful migration.
If I release a new major version (i.e. 2.0) with a new dependency the package might still be installed for loosy requirements settings (>=1.0
for example) and screw up all the existing data.
Ideally, the new core library should be installed and migrated, without losing tree information already stored in DB.
I would avoid platform specific libraries like django-ltree
or django-ltree-field
, and use instead a library that is well maintained like django-treebeard
, django-treenode
or django-tree-queries
. Which one, I don't know.
I am more than happy to accept pull requests with successful migrations included, and with all tests passing. To test new releases, I relied on django-groups-manager-migrator small project, where I am loading data, changing version, and run a small suit again.
mppt used to model group hierarchies is no longer maintained. This is probably not a big problem for a while.
Switching to another tree library could be done as part of a 2.0 release.