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

Chetan Mehrotra commented on OAK-6820:
--------------------------------------

Discussed this with [~catholicon] and we can do following

# On newer index definition set a mvp property {{supercedes}} which refers to 
path of existing index definition which it replaces
{noformat}
    /oak:index/assetType
      - jcr:primaryType = "oak:QueryIndexDefinition"
      - compatVersion = 2
      - type = "lucene"
      - async = "async"
      - supercedes = ['/oak:index/status', '/oak:index/assetType']
{noformat}
# IndexUpdate would check for this property. If present and current index 
"reindex" is false then it would check the "type" property of referred index 
paths. If they are not set to "disabled" then it would set them to "disabled". 
It would also set {{disabledOlderIndexes}} to true. This flag would be used to 
avoid this check for later indexing cycles
# If the index replaces yet another index later then it can remove the 
{{disabledOlderIndexes}} flag

[~catholicon] [~tmueller] Thoughts?

> 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
>
>
> 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)

Reply via email to