Hello, is this projected maintained

[Drzhivago264]

Hello,
I have seen your discussion in django-treenode repo and find your implementation of closure table here.
I want to ask:

1. Do you maintain this repo or do you want merge it to tree node?
2. I am not quire sure but I believe that closure table by itself is able to represent tree in sql, why would you use Adjacency List.
3. Do you use any recursive db call and if you did whether they are using CTE?
   Thank you for your support,

[Wizely99]

Hi @Drzhivago264,

I'll try to answer some of your questions here, as I've been using this package in my projects. I haven't experienced any serious issues so far, except for a few minor ones for which I've submitted a PR (#8). There's no recursive query—it's only a single query when trying to get descendants, ascendants, children, and siblings, thanks to the closure table. When retrieving the tree, a loop has been used (I believe a recursive query might be more suitable for this). You might want to look at this line for the loop.

Take my answer with a grain of salt.

[TimurKady]

Hi @Drzhivago264! Thank you for your attention to our work!

1. Yes, this project is actively maintained and will continue to evolve. There's a backlog of fantastic improvements developed by @Wizely99. Due to my current workload, I haven't been able to review all of them just yet. Moreover, I need to establish direct communication with him to clarify and discuss details. But rest assured, many of his enhancements are on my integration roadmap!

2. I've explained the reasons for using both Closure Tables and Adjacency Lists in the introduction. Check it out and browse through the linked resources for more details. The gist is, each method has its advantages for specific queries, allowing most tree queries to be executed with a single database call. It’s like having your cake and eating it too! :-)

3. No, there are no recursive database calls or any other kind of "forceful" interactions with it. All operations are conducted using standard SQL queries in a single pass. It’s smooth and gentle, just how our database likes it! :-)

[TimurKady]

Hi @Wizely99, thanks for getting back — no worries at all, I know how things can get!

That said — it’s a bit late to adjust now 🙂 I’ve since radically refactored the project, and the old caching mechanism is completely gone. In its place, I’ve implemented a new two-level caching system that’s significantly more performant, especially with large trees. It’s made a big difference in responsiveness and query efficiency.

So while I totally get the reasoning behind your change, the current architecture has moved quite a bit beyond that initial setup.

Still, I appreciate you keeping me in the loop — and feel free to share any future thoughts!

Cheers,
Timur