[ 
https://issues.apache.org/jira/browse/OAK-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Parvulescu updated OAK-3403:
---------------------------------
    Attachment: OAK-3403-v2.patch

Attaching a tweaked proposal based on [~chetanm]'s patch. The changes no longer 
introduce additional interfaces, I tried to simply treat the multiplexing bits 
as a layer of multiple index storage buckets. It still needs some work, but I'm 
interested to see if this could be the basis of discussion going forward. I 
also included changes for the {{ReferenceEditor}} which was changed on the 
mentioned git branches but not included in the current patch.

Unfortunately the setup boilerplate is still there, there's no way around it, 
so the bulk of my work was really around the {{PropertyIndexEditor}} and 
friends.

Looking forward to the feedback!

> 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, OAK-3403-v2.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