Hi,

I would probably use the JCR API as much as possible. That way you can
more easily switch between implementations (and that includes not just
Jackrabbit JCR implementations). Some details:

* I would not use same name siblings

* I would not use many (more than about 1000) child nodes in a node (flat
hierarchies).

* I would avoid using node types too much.


* As for queries, I would probably use XPath as it is simpler in many
cases.


As for Jackrabbit 2.x versus Jackrabbit Oak:

* Jackrabbit 2.x is there since a longer time, has more documentation.

* Jackrabbit Oak is relatively new, and probably still a bit "rough"
(documentation is not that clear for examle). Things are still changing
quite quickly. But eventually, it is or will be more flexible and scalable
(support larger repositories for example, more storage backends, more
indexes).

Regards,
Thomas



On 05/11/14 15:14, "Herrick, Rick" <[email protected]> wrote:

>We're in the process of working on an archive management system for our
>medical imaging data platform (XNAT, http://www.xnat.org). Currently we
>just manage files on the hosting file system, with all the issues that
>implies. We've been considering using Jackrabbit to manage all of the
>data resources (MRI, CT, PET and similar imaging data, synthetic data
>from processing and analysis pipelines, research subject data, etc.), but
>we have a few concerns.
>
>There doesn't seem to have been too much activity on this list, most of
>the articles on the Jackrabbit articles page are from 2011 and earlier,
>and most of the Jackrabbit news is actually about Oak.
>
>So is Jackrabbit still an on-going and supported platform? Should we be
>looking at Oak instead? Basically we don't want to embark on a full-blown
>development effort on something that may not be maintained. Or is just
>that, because this is a back-end technology, there's just not that much
>traffic and that's actually a GOOD thing (i.e. it's basically done and it
>works and no one complains)?
>
>Any thoughts on this would be very helpful and greatly appreciated.
>Thanks!
>
>--
>Rick Herrick
>Sr. Programmer/Analyst
>Neuroinformatics Research Group
>Washington University School of Medicine
>(314) 740-5961
>
>________________________________
>
>The material in this message is private and may contain Protected
>Healthcare Information (PHI). If you are not the intended recipient, be
>advised that any unauthorized use, disclosure, copying or the taking of
>any action in reliance on the contents of this information is strictly
>prohibited. If you have received this email in error, please immediately
>notify the sender via telephone or return mail.

Reply via email to