[jira] [Comment Edited] (OAK-5511) Reduce lookup for oak:index node under each changed node

["Vikas Saurabh (JIRA)" <ji...@apache.org>]

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

Vikas Saurabh edited comment on OAK-5511 at 2/23/17 6:15 PM:
-------------------------------------------------------------

From the thread \[0]
{quote}
for upgrade we can migrate the existing code by using nodetype
index to update all such "indexable" nodes
{quote}
I wonder if we could utilize this in all cases (well, not really querying). What I mean is what if we have an local registry (I'd say in-mem for simplicity... but I guess that's open for discussion) that is filled up by traversing {{/oak:index/nodetype/:index/oak:QueryIndexDefinition}} (and breaking at {{oak:index}} -- we can avoid leaves). Once that traversal is done, we can then have an observer that updates the registry.
(that, of course, assumes that {{nodeytpe}} is indexing {{oak:QueryIndexDefinition}} - to me that seems like a fair assumption... and, in any case, it can be handled by falling back to explicit look-up like today... and a WARN??? in the log??)

The obvious down-side is that the registry won't be rev-controlled - it'd match head state of the system. Otoh, {{IndexUpdate}} might be trying to look at some other revision. But, then that'd beg the question of why is IndexUpdate keen on looking for {{oak:index}} nodes which aren't there on head state?

PS: Admittedly, I haven't thought this through - but it seems that we already have this data in the repository (not as mixin on parent though). I think we might be better off utilizing that.
PS1: I don't mean to say really traverse the index structure - we should probably utilize {{ContentMirrorStoreStrategy}} to do it

\[0]: https://lists.apache.org/thread.html/53d6ecf9728678bb05530c5b4a7d3e340438cc71a54b9860a6d92aad@%3Coak-dev.jackrabbit.apache.org%3E


was (Author: catholicon):
From the thread \[0]
{quote}
For new setups we can enforce this
and for upgrade we can migrate the existing code by using nodetype
index to update all such "indexable" nodes
{quote}
I wonder if we could utilize this in all cases (well, not really querying). What I mean is what if we have an local registry (I'd say in-mem for simplicity... but I guess that's open for discussion) that is filled up by traversing {{/oak:index/nodetype/:index/oak:QueryIndexDefinition}} (and breaking at {{oak:index}} -- we can avoid leaves). Once that traversal is done, we can then have an observer that updates the registry.
(that, of course, assumes that {{nodeytpe}} is indexing {{oak:QueryIndexDefinition}} - to me that seems like a fair assumption... and, in any case, it can be handled by falling back to explicit look-up like today... and a WARN??? in the log??)

The obvious down-side is that the registry won't be rev-controlled - it'd match head state of the system. Otoh, {{IndexUpdate}} might be trying to look at some other revision. But, then that'd beg the question of why is IndexUpdate keen on looking for {{oak:index}} nodes which aren't there on head state?

PS: Admittedly, I haven't thought this through - but it seems that we already have this data in the repository (not as mixin on parent though). I think we might be better off utilizing that.
PS1: I don't mean to say really traverse the index structure - we should probably utilize {{ContentMirrorStoreStrategy}} to do it

\[0]: https://lists.apache.org/thread.html/53d6ecf9728678bb05530c5b4a7d3e340438cc71a54b9860a6d92aad@%3Coak-dev.jackrabbit.apache.org%3E

> Reduce lookup for oak:index node under each changed node
> --------------------------------------------------------
>
>                 Key: OAK-5511
>                 URL: https://issues.apache.org/jira/browse/OAK-5511
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Chetan Mehrotra
>              Labels: performance
>             Fix For: 1.8
>
>
> Currently {{IndexUpdate}} does a lookup for {{oak:index}} node under each changed node. This is done to pickup index definitions and create IndexEditor based on those so as to index content under that subtree. 
> This lookup results in extra remote calls on DocumentNodeStore based setup as for non leaf nodes NodeStore has to check from remote storage to determine if {{oak:index}} node is present or not.
> This lookup can be avoided by
> # Having an {{Editor}} which adds a hidden property {{:oak-index-present}} in parent node upon addition of {{oak:index}} as a child node
> # IndexUpdate would then does a lookup for {{oak:index}} node only if such a hidden property is found
> For upgrade we would have some logic which would make use of Nodetype index to identify all such nodes and mark them
> Discussion [thread|https://lists.apache.org/thread.html/70d5ffff0f950d7fc25bc1bbb41527f5672825f8cf2b238f54df2966@%3Coak-dev.jackrabbit.apache.org%3E] on oak-dev



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)