jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Müller <thomas.muel...@day.com>
Subject Re: [jr3] Flat hierarchy
Date Thu, 18 Feb 2010 16:04:54 GMT

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

If you are more comfortable with this view, that's OK. I probably
should have said: the whole repository is a "tree data structure".

> 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

Sure. Jackrabbit needs a way to quickly navigate to a node by path.
For that, you have to traverse the nodes and for each node you have to
find the correct child. To do that, it's better if the child node list
is ordered by name. Otherwise you have to iterate over all child nodes
until you find the right one. Or you need a secondary index (Lucene?).
And that's no matter if it's using a b-tree internally or not.

> 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

You only have to update the b-tree node that is modified. That may be
a hidden node (internal, hidden b-tree node) or a "real" node.


View raw message