Hi Thomas What about making the proposed solution built-in with Oak?
For example by defining a mixin type oak:Created extending from mix:created... the latter is already widely used and the oak extension could just offer the additional ability to be orderable upon search. In addition the solution would not need to be implemented multiple times. Kind regards Angela On 06/08/14 13:40, "Thomas Mueller" <[email protected]> wrote: >Hi, > >The following should work: > >- use a node type without _orderable_ child nodes >- in each node, add a property "created" with the timestamp plus a unique >id > >- to get the first entry, use a query ("order by created") > >This should scale well once synchronous, orderable indexes are >implemented. > >The problem with orderable child nodes is that in a cluster, this either >gets many conflicts or doesn't scale well. The problem with using a tree >structure ("/queue/2014-08/06T13/40_45") is that it's hard to implement. > >Please note that in Oak, right now, orderable indexes are not synchronous. >But I think this is a problem we can and should solve soon. Orderable >child nodes should also be improved in my view, but that's a area where we >know there are limitations. > >Regards, >Thomas > > >On 05/08/14 13:37, "Michael Dürig" <[email protected]> wrote: > >> >> >>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 <[email protected]> >>> Gesendet: Montag, 4. August 2014 20:02 >>> An: [email protected] >>> Betreff: Re: How to implement a queue in Oak? >>> >>> Hi, >>> >>> On Mon, Aug 4, 2014 at 8:04 AM, Felix Meschberger <[email protected]> >>>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 >>> >
