Hi, > Yes, but I think that's a relatively rare corner case. Besides, same > name siblings are not recommended in any case.
I agree, I was just not sure if this is really the implication. > Yes. One way to solve that would be to split large node records to > separate pieces that are loaded only on demand. Some data structure > like a B-tree would be nice, though it should support both orderable > nodes and same name siblings. Yes. One way to identify an item in an ordered list in a stable way is using simple fractions from the 'Applied number theory' in your blog (http://jukkaz.wordpress.com/2007/04/30/applied-number-theory/). This could also solve the same name sibling problem, and would allow reordering items in O(1) (maybe a 'reorg' is required from time to time if there are many changes). Unfortunately SQL databases don't support simple fraction indexes, not sure if this is a problem. > For now I'm happy with just a linear list of all the child nodes. With the current Jackrabbit: I agree. But I believe we need a solution for this in the future. > I'm not too concerned about hitting all parent nodes when accessing a > node. I am concerned if there is no faster way. > you'll in any case need to access all the parent nodes if you want > hierarchical access control. I hope there is a more efficient way. What about adding one bit to each node meaning "no access control below me". Then access control could stop where this bit is set. > As for the performance of the Lucene query. If it really ends up being > a problem, we can switch to a custom UUID index. Sure. This index would need to be updated whenever a value of the node changes, right? (That wouldn't necessarily be a problem if we mostly have read access). Regards, Thomas
