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')[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
