On Fri, Jan 20, 2012 at 4:09 PM, Thomas Mueller <muel...@adobe.com> wrote: > Hi, > > The current Jackrabbit implementation uses orderable child nodes by default, > meaning nodes are returned in the same order as they are created. As an > example, if I create the nodes /test/c, then /test/b, and then /test/a, and > then read the node list, I will get them back in that same order. I'm > wondering if this is really required (at all, and to be the default > behavior). Specially if there are a lot of child nodes. > > Instead of using the insertion order, I propose to sort the child node list > alphabetically: /test/a, /test/b, /test/c - no matter in what order the > nodes where created. This will allow an efficient lookup (using binary > search), and for large child node lists (more than one thousand child nodes > per node) modifications would be about twice as fast as using insertion > order (plus it would need less disk space). > > Would it be a problem if Jackrabbit 3 sorts child nodes by name (always, or > at least by default)?
i guess no. unless that this behavior is expected/mandated. > > Another option would be to use (insertion) order until the child node list > gets too large (for example 1000 elements), and from then on sort the child > nodes by name (the previous ordering would then be lost). i am currently working on a similar approach in the microkernel prototype (sandbox). i am thinking about switching from 'insertion ordered' to 'unordered' (the order depends on the implementation, in my case it's based on the hashcode of the child node name) once a certain threshold is reached. cheers stefan > > Regards, > Thomas >
