Hi 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). 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 ? Regards Felix Am 01.08.2014 um 07:56 schrieb Carsten Ziegeler <cziege...@apache.org>: > I'm wondering if anyone has a good idea how to model a queue with efficient > operations in JCR - or is JCR not suited for this use case? > > Regards > Carsten > > > 2014-07-30 15:57 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > >> Using a different storage than JCR would be easy in my case, however I >> *want* to use JCR >> >> Carsten >> >> >> 2014-07-30 14:55 GMT+02:00 Lukas Smith <sm...@pooteeweet.org>: >> >> Hi, >>> >>> I can totally see that it might be useful to be able to go through the >>> Oak/JCR API to have a queue but maybe this is stretching Oak a bit far if >>> you end up with 1k+ queues. >>> >>> However I think it would be great to look more into federation for this. >>> I think ModeShape supports this quite well already, ie. being able to hook >>> in another JCR tree, a file system, a git repository, CMIS .. I am sure >>> that it would also be possible to implement on top of some MQ standard. >>> >>> see also https://docs.jboss.org/author/display/MODE/Federation?_sscc=t >>> >>> regards, >>> Lukas >>> >>>> On 30 Jul 2014, at 14:41, Angela Schreiber <anch...@adobe.com> wrote: >>>> >>>> hi carsten >>>> >>>> if you are expecting your nodes to be in a given order (e.g. the >>>> order of creation) you need to have a parent that has orderable >>>> children... in which case we don't make any promises about huge >>>> child collections... it will not work well. >>>> >>>> if you don't have the requirement of ordered children, you can >>>> have _many_ but need to make sure that your parent node doesn't >>>> have orderable children (e.g. oak:Unstructured)... but then you >>>> cannot expect that new children are appended at the "end of the >>>> list"... there is no list and there is not guaranteed order. >>>> >>>> i guess you have a little misunderstanding when it comes to >>>> the concept of orderable child nodes -> JSR 283 will be your friend. >>>> >>>> regards >>>> angela >>>> >>>>> On 30/07/14 13:27, "Carsten Ziegeler" <cziege...@apache.org> wrote: >>>>> >>>>> Hi, >>>>> >>>>> afaik with Oak the too many child nodes problem of JR2 is solved, >>>>> therefore >>>>> I'm wondering what the best way to store a queue in the repository is? >>>>> >>>>> In my use cases, there are usually not many items within a single >>> queue, >>>>> let's say a few hundreds. In some cases the queue might grow to some >>>>> thousands but not more than maybe 20k. >>>>> >>>>> The idea is that new entries (nodes) are added to the end of the queue, >>>>> and >>>>> processing would read the first node from the queue, update the >>> properties >>>>> and once done, remove it. >>>>> >>>>> My initial design was to simply store all entries as sub nodes of some >>>>> queue root entry without any hierarchy. addNode should add them at the >>> end >>>>> and simply iteration over the child nodes of the root gives the first >>>>> entry. No need for sortable nodes. >>>>> >>>>> Does this make sense? Is there anything else to be considered? >>>>> >>>>> Regards >>>>> Carsten >>>>> -- >>>>> Carsten Ziegeler >>>>> Adobe Research Switzerland >>>>> cziege...@apache.org >>>> >>> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
