On 6/21/07, Frédéric Esnault <[EMAIL PROTECTED]> 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')[EMAIL PROTECTED]: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
