[ 
https://issues.apache.org/jira/browse/OAK-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15354661#comment-15354661
 ] 

Thomas Mueller commented on OAK-3403:
-------------------------------------

The patch is quite large, and changes the existing index implementations quite 
a lot. Backporting fixes will be very hard for example, and there is quite a 
risk of bugs (sure, we have tests).

An alternative (to be discussed) might be to have: at update time, independent 
indexes (the existing property index); and at query time, a new index type 
"multiplex" that combines the result of multiple indexes. So for example, lets 
say there is an index for the property "color", and two repositories, one for 
"/lib" and one for the rest excluding "/lib". Instead of one index, this would 
result in 3 indexes:

* /oak:index/colorContent (excludedPaths = "/lib", type = "property")
* /oak:index/colorLib (includePaths = "/lib", type = "property")
* /oak:index/color (type = "multi", list = "colorContent", "colorLib")

Disadvantage: configuration would be more complex. Advantage: much simple to 
implement, less risky. I might be so simple to implement that we can do both: 
longer term your patch, short term the "multi" index (in a new issue).


> Multiplexing store support in Property indexes
> ----------------------------------------------
>
>                 Key: OAK-3403
>                 URL: https://issues.apache.org/jira/browse/OAK-3403
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: query
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>         Attachments: OAK-3403-v1.patch
>
>
> In Oak one can define an index anywhere in the repository under a special 
> node name {{oak:index}}. For e.g. if you want a property index for 
> {{sling:resourceType}} at root level then you can create the index at 
> /oak:index/resourceType and this index would store the index content at 
> /oak:index/resourceType/:index.
> # Writing - At time of commit the IndexEditor would need to decide where the 
> indexed content for a given path should be stored. To start with it can make 
> use of PathToStoreMapper to decide which node to use the indexed content. For 
> e.g. for /libs the indexed content is stored under :index-pr and for /content 
> :index-sr is used. This is simpler for PropertyIndex where IndexStoreStrategy 
> can be passed the right node
> # Reading - At time of reading the QueryIndex implementation would need to 
> provide a union cursor which can perform lookup from all such store 
> directories for a given index. 
> *Open Items*
> # Supporting unique indexes
> # Introducing new oak:index - Node under oak:index node are special. 
> Depending on parent path it might be possible that they would have to be 
> created in both repositories. For e.g. /oak:index would have to be present in 
> both PR and SR. While /content/foo/oak:index can live only in SR. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to