On 20.01.12 16:09, "Thomas Mueller" <muel...@adobe.com<mailto:muel...@adobe.com>> wrote:
The current Jackrabbit implementation uses orderable child nodes by default, meaning nodes are returned in the same order as they are created. I think "same order as they are created" is not really "orderable child nodes" - if a node does not have the orderable flag, you cannot re-order them (through the API). I'd call this default behavior simply "appending". And I think for nodes with the orderable flag, this is a good default behaviour and shouldn't be changed.... 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. ...but for non-orderable nodes (i.e. a big "bunch") I agree that alphabetical order by default is good. Based on experience, all the UIs for non-orderable nodes (e.g nt:hierarchyNodes) end up doing alphabetical ordering anyway (for the default view and if they don't allow for custom display ordering), as that's what makes it easy for humans to find the way around. 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). Isn't the current appending the simplest and fastest? Would it be a problem if Jackrabbit 3 sorts child nodes by name (always, or at least by default)? Yes, but for non-orderable nodes only, of course. For orderable nodes I think a goal should be to keep the list ordered the whole stack down (API, in-memory, in-between formats (like json) and persistence layer), to handle it efficiently. I.e. without any "ordering number" column and thus requiring re-orderings at some level. 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). Hmm, that would take away the benefit of the alphabetical default order, as applications would still need to order it alphabetically in UIs (for the lists shorter than 1000 elements). Cheers, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
