[
https://issues.apache.org/jira/browse/OAK-6820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204997#comment-16204997
]
Chetan Mehrotra edited comment on OAK-6820 at 10/15/17 2:55 AM:
----------------------------------------------------------------
bq. while validating existence of superceded index def with declaredNodeTypes
and not finding type after @ in declaredNodeTypes - maybe we should warn
That was my initial thought. But then we would need to have different index
definitions for upgrade and non upgrade case. As for fresh setups those
nodetype entries would anyway not be there
bq. there could be a case where we only update the def to supercede an (async)
index def but not reindex yet - that, afaics, would lead to disabling
superseded defs in next cycle (as reindex flag wouldn've have changed in the
cycle)
Good point. What about we change the logic slightly.
# IndexUpdate would set a hidden flag {{:disableIndexesOnNextCycle}} if it
finds during reindexing
## that current index has {{supersedes}} specified
## And those supersedes refer to indexPaths which have yet not be disabled
# IndexDisabling logic would then only be activated if that flag is present.
And then we do not require managing {{disabledOlderIndexes}}. Post disabling it
would remove that hidden flag
This approach would ensure that indexes are only and only disabled post reindex
as such a hidden flag can only be set by system after due validation
Thoughts?
was (Author: chetanm):
bq. while validating existence of superceded index def with declaredNodeTypes
and not finding type after @ in declaredNodeTypes - maybe we should warn
That was my initial thought. But then we would need to have different index
definitions for upgrade and non upgrade case. As for fresh setups those
nodetype entries would anyway not be there
bq. there could be a case where we only update the def to supercede an (async)
index def but not reindex yet - that, afaics, would lead to disabling
superseded defs in next cycle (as reindex flag wouldn've have changed in the
cycle)
Good point. What about we change the logic slightly.
# IndexUpdate would set a hidden flag {{:disableIndexesOnNextCycle}} if it
finds during reindexing
## that current index has {{supersedes}} specified
## And those supersedes refer to indexPaths which have yet not be disabled
# IndexDisabling logic would then only be activated if that flag is present.
And then we do not require managing {{disabledOlderIndexes}}. Post disabling it
would remove that hidden flag
This approach would ensure that indexes are only and only disabled post reindex
as such a hidden flag can only be set by system after due validation
> Implement support for disabling indexes which are replaced with newer index
> ---------------------------------------------------------------------------
>
> Key: OAK-6820
> URL: https://issues.apache.org/jira/browse/OAK-6820
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.8
>
> Attachments: OAK-6820-v1.patch
>
>
> For upgrade case in many applications older index type is set to {{disabled}}
> when new index is provisioned. If the new index is async then it would take
> some time for reindex and till then any query which used to make use of old
> index would end up traversing the repository
> To avoid such a scenario we should only mark older index as "disabled" only
> if the newer index is reindex.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
