There are the utilities in the org.apache.jackrabbit.commons.flat
package, which were built for mapping flat structures to a JCR
hierarchy. See the BTreeManager class for a good starting point.
Michael
On 1.8.14 7:56 , Carsten Ziegeler wrote:
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
