[
https://issues.apache.org/jira/browse/OAK-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15701623#comment-15701623
]
Tom Blackford commented on OAK-4400:
------------------------------------
I think this is quite an important improvement for larger deployments.
In environments where re-indexing is slow (lots of binaries, 'remote datastore'
i.e. S3) the current behaviour can be quite a challenge, as until a modified
index has been re-indexed, queries won't necessarily include all results. Even
with pre-extraction configured, re-indexing time might be several hours, which
is a long time to leave an environment in an inconsistent state.
> Correlate index with the index definition used to build it
> ----------------------------------------------------------
>
> Key: OAK-4400
> URL: https://issues.apache.org/jira/browse/OAK-4400
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene, query
> Affects Versions: 1.4
> Reporter: Valentin Olteanu
> Fix For: 1.8
>
>
> Currently, if the definition of an index is changed without reindexing, it
> will get in an "inconsistent" state.
> Of course, the reindexing is usually necessary, but it would be useful to
> know with which definition the index was built. This could increase the
> visibility of the indexing state and help debugging issues related to it.
> Some questions this improvement should respond to:
> # What is the definition of the index when the (re)indexing was triggered?
> # Are there any changes in the definition since the trigger? Which?
> I can imagine a solution built by "versioning" the definition nodes
> (oak:QueryIndexDefinition). When the reindex is triggered, a new version of
> the node is created and the indexer stores a reference to it.
> This would also allow the indexer to keep using the same definition until a
> new reindex, even if changes are made meanwhile (i.e. use a fixed version
> instead of the latest definition).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
