vittoriozamboni / django-groups-manager

Manage django groups collection based on django-mptt.
MIT License
100 stars 23 forks source link

Think about a replacement for mptt (no longer maintained) #71

Open dalito opened 1 year ago

dalito commented 1 year ago

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.

vittoriozamboni commented 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.

yellowsoar commented 1 year ago

There are a few more packages that do the same thing as mppt.

And some Postgres only packages

rxm7706 commented 1 year ago

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.

dalito commented 1 year ago

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).

jokiefer commented 1 year ago

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.

vittoriozamboni commented 1 year ago

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.