Hi, I guess one problem is that the default node type, nt:unstructured, supports orderable child nodes: http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.13.1%20nt:unst ructured "This node type also supports client-orderable child nodes." I guess "client-orderable" also means "insertion order".
If we use alphabetical child node lists by default for Jackrabbit 3, then we would need to use a different default node type? Is it even possible to use a different node type than nt:unstructured in Jackrabbit 3? Regards, Thomas On 1/20/12 4:26 PM, "julian.resc...@gmx.de" <julian.resc...@gmx.de> wrote: >On 2012-01-20 16:09, Thomas Mueller 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)? >> ... > >Spec-wise the returned ordering shouldn't matter unless the node type >indicates that the child nodes are indeed ordered. > >If we suspect that there's code out there making other assumptions, we >may want to change that in an earlier jackrabbit release to find out for >sure :-)
