Hi, >> I would also use a b-tree structure. If a node has too many child >> nodes, two new "invisible internal nodes" are created, and the list of >> child nodes is split up. Those internal nodes wouldn't have any >> properties. > > You mean a b-tree for each node? I think this could be a separate > index, but one for the whole tree.
The repository is one large b-tree, and each JCR node is a b-tree node (except for the JCR nodes that don't have any child nodes: those are b-tree leaves). If a JCR node has many child nodes, then there is at least one more level of b-tree nodes between the node and the child nodes. > I think supporting fast path lookups for orderable child nodes is a > bit more important than flat hierarchies Path lookups would still be fast (the same speed as now), except for large child node lists that were re-ordered. The difference is only for large child node lists. There is a difference between 'orderable' nodes (have the ability to reorder the child node list) and actually 're-ordered' child node lists. Is it acceptable if new nodes appear in lexicographic order in the child node list? Regards, Thomas
