On Mon, Nov 29, 2010 at 4:48 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > Great discussion! I've recently started looking at ways to implement the > "search collection" stuff Alex referred to, and it would be great if this > discussion could end up helping design such an implementation. We should > move to dev@ for the details.
I am really not in favour. I anticipate lot's of issues, and home-grown solutions build on top of Lucene to get it all working. We should strive for simplicity imo, and go 'back' to as close to Lucene as possible. Regarding 'search collections', what is the next step after the 'path based' collections? ACL-based collections? I don't believe it will ever work, and will add tons of complexity. > > PS. Regarding index-in-JCR, nowadays with a file-based data store a Lucene > search index stored and accessed as JCR nodes and properties should be > pretty efficient... No, it can't be efficient. Lucene is highly optimized for storage on filesystem (or memory). You'll loose this when accessing it through jcr nodes. I just don't see how it could ever perform. Every attempt I have seen to store Lucene differently than on FileSystem or in memory fails very soon on scalability. Also, storage in Lucene 4.0 completely changes. This would mean, that the 'jcr' mapped indexes would again need to change. We shouldn't go that route, and, it is not needed imo! Strive for simplicity and close to plain Lucene library usage and as few as possible own classes I strongly prefer Regards Ard > > BR, > > Jukka Zitting > -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 185 H Street Suite B • Petaluma CA 94952-5100 • +1 (707) 773 4646 Canada • Montréal 5369 Boulevard St-Laurent • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • [email protected]
