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