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
