It seems a closure tree storage could be simpler than a nested set storage like the one currently used.

Attached is a standalone module implementing this type of storage, hopefully pluggable into this module, as I haven't yet had time to understand the structure of all the files involved in the current module implementation.

CommentFileSizeAuthor
#5 entity_tree.pdf1.35 MBmitchell
#4 0001-Add-ClosureTableLength-provide-to-providers-director.patch16.88 KBfgm
treect.tgz14.83 KBfgm

Comments

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Title: Closure Tree storage » Closure Table Tree storage

incomplete title!

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

first: damien thanks for hacking this together!!

then a big +1 for this issue.

if someone wants to come the conclusion themself that closuretable is a stron implementation see the links in #277312-9: Propose your change to taxonomy module in core

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

Better version coming hopefully this week: it already includes two fixes over the previous one, preventing illegal moves (node to one of its children) and illegal adds (multiple roots).

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Active » Needs work
StatusFileSize
new 0001-Add-ClosureTableLength-provide-to-providers-director.patch16.88 KB

Better version, now with some integrity tests and start of a test suite.

mitchell’s picture

mitchell commented
StatusFileSize
new entity_tree.pdf1.35 MB

* chx has an interesting storage optimization in Entity Tree.
* Could it be made into a pluggable backend for this patch?
* #1669052: Port to a backend storage mechanism for Entity Reference's Tree plugin would be a better place to discuss.
* This entity_tree presentation he posted in #28480: Create generalized relationship module explains it very well.