jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: [jr3] Orderable child nodes: required (to be the default)?
Date Fri, 20 Jan 2012 15:43:11 GMT
On 20.01.12 16:09, "Thomas Mueller" <mueller@adobe.com<mailto:mueller@adobe.com>>

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).


Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message