jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: [jr3 trade consistency for availability]
Date Fri, 24 Feb 2012 22:30:17 GMT
Am 23.02.2012 um 11:26 schrieb Ard Schrijvers:
> I've come to believe over the years, that a generic
> hierarchical jcr full text index and queries is a bad idea : In the
> end, it just doesn't scale, is extremely complex to build (Lucene is
> flat), and even worse, it doesn't seem to satisfy customers/developers
> in the end: They want to index and search *their* specific model they
> store in jackrabbit. You can tweak a bit with indexing_configuration
> kind of things, but in the end, I think a (Lucene) index is just to
> domain specific

Huge +1.

Allowing to create & define separate search indexes based on some rules (subpath, all
cq:Page nodes, similar to indexing_config) would be a really helpful improvement.

One of the main CMS search uses cases is to have different full text search indexes for different
sites, say /site1 and /site2. Currently you have to include a location step "/jcr:root/site1//*[jcr:contains(.
'foo')]" which is not indexed due to the optimization for moves, making this much slower than
necessary. Separate indexes for site1 + site2 would solve this easily.

Also, we loose a lot of Lucene's features by hiding them under the search implementation tied
to the JCR query specifications. Opening this up would make improvements and/or extensions
for search index configurations much easier.


Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message