On 5.8.14 12:22 , Christian Keller wrote:
Jumping in here, where the thread developed to a discussion about the
repository implementation of orderable Nodes.
I like to come back to the use-cases needed.
These can be summarized that I expect a certain order upon access of the Node's
NodeIterator.
That order is up to the implementation and applications should not
depend on this. See 23.5 Non-orderable Child Nodes:
http://www.day.com/specs/jcr/2.0/23_Orderable_Child_Nodes.html#23.5%20Non-orderable%20Child%20Nodes
In any cases I had in CQ there was never a requirement of strict ordering.
But it was used to allow a user defined order: The Page-Order in the navigation.
So I wonder if a basic non strict order to allow for JCR order support is
sufficient.
For any other orders I wonder if an additional method to
Nod#getNodes(Comparator) would not be sufficient.
As I don't think this can scale to many child nodes, you could use an
orderable node type as well.
Michael
With this you can move the burden of ordering on access.
A time sequence for child-node could be easily achived on the jcr:created
Property
Regards
Christian
________________________________________
Von: Jukka Zitting <ju...@zitting.name>
Gesendet: Montag, 4. August 2014 20:02
An: oak-dev@jackrabbit.apache.org
Betreff: Re: How to implement a queue in Oak?
Hi,
On Mon, Aug 4, 2014 at 8:04 AM, Felix Meschberger <fmesc...@adobe.com> wrote:
I have the impression, that JCR itself can adequately solve the problem using
ordered child nodes.
The problem is not JCR per-se but the implementation and the early-on decision
to not optimize
the use case of ordered child nodes (in favor of having support for optimized
implementation of
the unsorted case).
The preference against ordering is more than just a performance
optimization. Maintaining strict ordering semantics is impossible in
an eventually consistent system with no global synchronization. For
example, if two clients on different cluster nodes add entries at the
end of the list at the same time, which entry should come first? And
how do we ensure that the ordering remains consistent across all
clients?
Now with Oak, we also have customizable indices. Would it be possible to define
an ordering
property, index that property and then use a query to get these nodes. The
query could be
created such that the ordering property index would be considered (only). As a
result we get
quick and transparent sorted nodes?
Yes, that's possible. My "order by node name" suggestion works roughly
in the same way. The problem with these approaches is that you won't
get strict ordering semantics without some external synchronization or
a global clock to decide how the values of the ordering property
should be assigned. However, it sounds like in Carsten's case relaxed
ordering semantics based on millisecond timings from the system clock
should be good enough.
BR,
Jukka Zitting
