[
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-v6.patch
attaching [v6 version|^OAK-3403-v6.patch] with new cost method, [~chetanm]
could you please take a look.
bq. There are quite many places where we do "for (IndexStoreStrategy s...". Not
sure if would be better to create some kind of a "MultiplexIndexStoreStrategy".
Maybe it would complicate the code more than it would help.
I stayed away from introducing a MultiplexIndexStoreStrategy as I don't think
it fits the purpose. I find refactoring the code to use a list instead of a
single instance cleaner.
bq. It has some new TODOs and, maybe we should create issues for those?
right, they are mainly around collecting/tracking index definition nodes. Not
sure how consistency is enforced here wrt. adding/removing multiplexers, ie.
what happens if I remove a multiplexer mapping and the dedicated index storage
is still there? While this will probably be tracked at tooling level, it might
still make sense to add some sort of consistency check in the indexing code
(like maintaining the list of strategies in the index definition).
bq. Maybe some randomized tests could be added. But probably it makes sense to
do that on a higher level (a stable API such as the JCR API), so that the tests
can be re-used later on, without having to refactor all those tests.
I agree with adding more tests at a higher level, but this might not
necessarily be a part of this specific issue, at least I don't have any plans
to add any with this patch.
> 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, OAK-3403-v3.patch,
> OAK-3403-v4.patch, OAK-3403-v5.patch, OAK-3403-v6.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)
