atom feed29 messages in org.apache.jackrabbit.oak-devOn custom index configuration
FromSent OnAttachments
Jukka ZittingSep 18, 2012 8:13 am 
Lukas Kahwe SmithSep 18, 2012 8:16 am 
Jukka ZittingSep 18, 2012 8:19 am 
Thomas MuellerSep 18, 2012 8:30 am 
Jukka ZittingSep 18, 2012 9:04 am 
Thomas MuellerSep 18, 2012 11:56 pm 
Thomas MuellerSep 19, 2012 1:06 am 
Jukka ZittingSep 19, 2012 2:02 am 
Thomas MuellerSep 19, 2012 3:07 am 
Alexander KlimetschekSep 19, 2012 5:00 am 
Thomas MuellerSep 19, 2012 5:26 am 
Bertrand DelacretazSep 19, 2012 6:47 am 
Lukas Kahwe SmithSep 19, 2012 6:50 am 
Bertrand DelacretazSep 19, 2012 7:05 am 
Ard SchrijversSep 19, 2012 12:30 pm 
Jukka ZittingSep 19, 2012 1:39 pm 
Lukas Kahwe SmithSep 19, 2012 1:46 pm 
Ard SchrijversSep 19, 2012 2:29 pm 
Tommaso TeofiliSep 20, 2012 5:44 am 
Lukas Kahwe SmithSep 20, 2012 5:48 am 
Thomas MuellerSep 20, 2012 6:10 am 
Jukka ZittingSep 20, 2012 6:13 am 
Lukas Kahwe SmithSep 20, 2012 6:16 am 
Jukka ZittingSep 20, 2012 6:20 am 
Jukka ZittingSep 20, 2012 6:24 am 
Thomas MuellerSep 20, 2012 7:49 am 
Jukka ZittingSep 20, 2012 8:51 am 
Thomas MuellerSep 20, 2012 10:49 am 
Jukka ZittingSep 20, 2012 11:15 am 
Subject:On custom index configuration
From:Jukka Zitting (jukk@gmail.com)
Date:Sep 18, 2012 8:13:38 am
List:org.apache.jackrabbit.oak-dev

Hi,

We now have a couple of initial index implementations for Oak and some ideas on how index configuration could/should work. In order to start unifying those approaches and to find some common consensus, I'd like to throw out an idea of how I think index configuration should work in Oak. Critiques, improvements or competing ideas welcome!

First of all I think there shouldn't be just one single place in the repository where all index configuration should go. It would be nice if users and applications could define custom indexes on areas they have write access to, and having to grant them access to some shared location for that might be troublesome.

Instead I'd allow a custom indexes to be defined by adding something like an oak:indexed mixin type and an associated oak:indexes child node to any node in the repository. Each child node of that oak:indexes node would configure an index for the subtree rooted at that oak:indexed node. Index configuration would be stored as normal content, and the index content in a hidden :index subtree or elsewhere depending on the type of the index.

For example, here's what a content tree that defines a unique jcr:uuid index at the root of a workspace, a normal jcr:title property index for content under /articles and a Lucene full text index for nt:file nodes under /data:

/ [jcr:mixinTypes = oak:indexed] /oak:indexes /uuid [jcr:primaryType = oak:uniqueIndex, oak:propertyName = jcr:uuid] /:index { invisible index content } /articles [jcr:mixinTypes = oak:indexed] /oak:indexes /title [jcr:primaryType = oak:propertyIndex, oak:propertyName = jcr:title] /:index { invisible index content } /data [jcr:mixinTypes = oak:indexed] /oak:indexes /fulltext [jcr:primaryType = oak:fulltextIndex, oak:nodeType = nt:file] /:index { invisible index content }

Creating a new custom index would be a matter of adding the appropriate index configuration settings. For example, the following code would define an additional jcr:created property index under /articles:

Session session = ...; Node indexes = session.getNode("/articles/oak:indexes"); Node created = indexes.addNode("created", "oak:propertyIndex"); created.setProperty("oak:propertyName", "jcr:created"); session.save();

Creating such an index node would trigger automatic indexing of the subtree, either directly in a commit hook or as a delayed background processing job. All future commits to that subtree would automatically get indexed since the commit hook would notice the index configurations in the oak:indexes node as it traverses down the commit diffs.

When executing a query, the search engine in Oak would then detect all indexes along the main path axis of a given query. For example, when querying for content inside /data/foo, the search engine would use the indexes at / and /data, but not the ones at /articles.

Removing a custom index would be a simple matter of removing the respective index configuration node. For example, to remove the full text index defined above, one would do:

Session session = ...; session.getNode("/data/oak:indexes/fulltext").remove(); session.save();

BR,