Hi, > It is not yet "wired" to
That touches on the original question. How can I wire in an indexing strategy (lucene or not) using the current api? alex On Thu, Mar 22, 2012 at 9:36 AM, Thomas Mueller <[email protected]> wrote: > Hi, > > >OAK-36 covers the Query implementation effort, but I'm wondering if now > >would be a good time to mention indexing as well. > > > >We want to have dedicated indexes, I think that would be accomplished via > >observation. > >Any ideas about the availability of this feature? > > Sure. One such a mechanism is implemented, and currently lives under > org.apache.jackrabbit.mk.index. It is not yet "wired" to > org.apache.jackrabbit.oak.query.index. This mechanism stores the index > data in nodes and properties, as a tree (using just the MicroKernel API). > This mechanism is supposed to be as scalable as the MicroKernel > implementation (support concurrent writes if the MicroKernel > implementation supports it). > > >The current index implementation just traverses the existing nodes (albeit > >applying some path constraints first), > > Yes, that's org.apache.jackrabbit.oak.query.index.TraversingReader > > >This helps with testing the query parser & friends, but a lucene based > >query engine needs events to update its data. > > Given the scalability requirements defined at [1] (specially concurrent, > scalable writes in multiple cluster nodes) we plan to support other > (non-Lucene) index mechanisms as well. Personally, I believe we should use > Lucene for fulltext indexing, because that's what Lucene is meant for. But > I'm not sure how a fully scalable fulltext index using Lucene would look > like. That's still an open question we need to resolve, or define the > limitations in this area. > > [1]: > http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrab > bit%203 > > Regards, > Thomas > >
