Thanks Angela, alright then, as a queue needs ordering the parent needs to be orderable in which case Oak will not work well. Which means I need to stick with the ugly workarounds I have already for JR2.
Carsten 2014-07-30 14:41 GMT+02:00 Angela Schreiber <[email protected]>: > 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" <[email protected]> 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 > >[email protected] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
