jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Esnault <f...@legisway.com>
Subject About Jackrabbit repository model
Date Thu, 21 Jun 2007 06:10:37 GMT
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;

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

 

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message