I think Jukka is correct that the correct use of B-trees is to use one for each list of child nodes, not as a way to model the entire hierarchy. I've seen this implementation approach used for similar use cases, so I know that it can work. And there are modifications that can easily be applied to B-trees that deal with arbitrary (not based on a key) ordering of the nodes, even allowing you to skip to the n-th child efficiently (without having to traverse the entire tree).
The part that's not clear to me is how this can be efficiently combined with an append-only storage format that's being discussed on the "[jr3] Unified persistence" thread. It wouldn't be good if every time a list of children is modified the persistence layer has to make a complete copy of the modified B-tree, as that would defeat the purpose of use a b-tree in the first place, wouldn't it? Jeff -- View this message in context: http://n4.nabble.com/jr3-Flat-hierarchy-tp1558925p1560288.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
