jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Orderable child nodes: required (to be the default)?
Date Fri, 20 Jan 2012 16:43:23 GMT
Hi,

Thinking about this more generally, it would definitely be useful to
be able to use a more efficient underlying storage for unorderable
nodes. However, there still are hard use cases that require us to
support orderable nodes as indicated by the type of the parent node.
Thus the implementation basically has two options:

1) Use a single data structure for all nodes, like Jackrabbit
currently does. This simplifies the implementation but prevents us
from enjoying the performance and scalability benefits of unorderable
nodes.

2) Use two data structures, one for orderable and another for
unorderable nodes. This is more complex (not least because it links
node types to the underlying storage model), but is probably required
if we want to efficiently support up to millions of child nodes per a
single parent.

It might also be possible to have the underlying storage model
unorderable, and just include extra ordering metadata at a higher
layer where also node types are handled. Option 2b, if you like, with
probably fairly significant overhead when iterating over nodes (the
implementation would probably need to pre-fetch all child nodes in
advance to access their ordering metadata).

If we do have native support for unorderable nodes, then I wouldn't
promise any particular ordering (alphabetic, insertion order, etc.)
but rather leave it undefined like in Java's Map interface. The
underlying implementation is then free to use whatever ordering it
thinks is best.

PS. Note that ordering affects not just node traversal, but also the
document ordering used in search results. Though in practice we
already now disable document ordering of search results by default.

BR,

Jukka Zitting

Mime
View raw message