Hi, On Jan 14, 2008 5:15 PM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > The path is not always stable across revisions, for example when using > same name siblings. That means in the following example deleting > customer[1] would result in 1001 Lucene index updates, because the > path of all invoices would change?
Yes, but I think that's a relatively rare corner case. Besides, same name siblings are not recommended in any case. > > A parent node contains the names and SHA-1 record checksums of all the > > child nodes. > > That means flat hierarchies (many child nodes per node) would still be > a problem (like now)? 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. For now I'm happy with just a linear list of all the child nodes. > I believe there are a few problems: Lucene queries are relatively > slow, and for flat hierarchies you need to read a lot of data. In > addition to the Lucene query, you need one persistent storage access > per path element. I'm not too concerned about hitting all parent nodes when accessing a node. Most of the time the parent records will already be cached and you'll in any case need to access all the parent nodes if you want hierarchical access control. As for the performance of the Lucene query. If it really ends up being a problem, we can switch to a custom UUID index. > I'm afraid this architecture would be a lot slower than the current > Jackrabbit: In the current architecture, there is only one persistent > storage access (and no Lucene query) required to read one node > (bundle) using the unique UUID. Agreed. As noted in my opening message, this is a conscious tradeoff. Whether it's a lot slower or just somewhat slower and how much that would affect typical applications remains to be seen. This is one of the key reasons why I want to build a working prototype before seriously considering an architecture like this for jackrabbit-core. BR, Jukka Zitting
