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
