jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: About Jackrabbit repository model
Date Thu, 21 Jun 2007 07:51:15 GMT
On 6/21/07, Frédéric Esnault <fesn@legisway.com> wrote:
> Hi there !
>
>
>
> I've been thinking about what I've been told here.
>
> It has been said that :
>
> -          Jackrabbit doesn't like same name siblings, so it would be better to give
nodes specific names;

it's not that Jackrabbit "doesn't like it", it's because samename
siblings cause a lot of issues from a user perspective (e.g. the path
'/a/b[2]' is not stable since it might become
'/a/b[1]' if '/a/b[1]' were removed).

>
> -          Jackrabbit doesn't like too many child nodes under on same nodes (ie. 1000
or more child nodes for one parent node)

jackrabbit's implementation is optimized for small to medium sized
child node sets.
performance tests showed that up to ~20k child nodes there's no significant
negative performance impact.

cheers
stefan

>
>
>
> But I don't think my repository structure is unique. My repository has one business root
(lgw:root) with (currently) three category child nodes :
>
> -          contacts;
>
> -          contractors;
>
> -          contracts;
>
> And each of them (say contacts) hold all the nodes of this category (all the contacts),
and the contact nodes are all called lgw:contact.
>
> This breaks the two "jackrabbit doesn't like" rules said before, but I think this is
not a strange architecture. I saw here on this mailing list someone
>
> talking about his repository holding books, authors and so on... I guess his nodes are
called book or ns:book (if ns is his namespace), with
>
> properties and child nodes, and all have the same parent.
>
>
>
> It seems that searching one this kind of architecture takes ages, I made a search yesterday
that I stopped after 25 minutes.
>
>
>
> /jcr:root/lgw:root/lgw:contracts/lgw:contract/jcr:deref(@lgw:internalContractor, 'lgw:contractorType')[@lgw:companyName='Legisway']
>
>
>
> This is a search on ALL the contracts, and on each contract, it dereferences an uuid
on ALL internal contractors (multivalued property) and applies a predicate
>
> on the contractor nodes. This is, for us, a very classic search (find contracts signed
with a specific company), and this search should be fast. 25 minutes is not
>
> acceptable.
>
>
>
> Is there documentation on how jackrabbit uses Lucene, how indexes are built and on what,
and is jackrabbit going to deal better with such architectures (which, once again,
>
> I think is quite common)?
>
>
>
> Frederic Esnault
>
>

Mime
View raw message