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. Cheers, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
