jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-4400) Correlate index with the index definition used to build it
Date Mon, 05 Dec 2016 14:08:58 GMT

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

Vikas Saurabh edited comment on OAK-4400 at 12/5/16 2:08 PM:
-------------------------------------------------------------

I like (B) because it's very straight-forward without relying too much on other mechanics
- to me it seems that the state we want to save is long living while the revision based branching
isn't _supposed_ to used as source control. Moreover, I'm not comfortable with A-3 - what
does it mean to get {{null}} from stored checkpoint and then falling back to current node
state... can it be used as a guarantee that we are still working as expected?

BTW,
bq. ... as any change done in index definition would not reflect in query 
I wonder how to make this more easily discoverable? This can get confusing very quickly.


was (Author: catholicon):
I like (B) because it's very straight-forward without relying too much on other mechanics
- to me it seems that the state we want to save is long living while the revision based branching
isn't _supposed_ to used as source control. Moreover, I'm not comfortable with A-3 - what
does it mean to get {{null}} from stored checkpoint and then falling back to current node
state... can it be used as a guarantee that we are still working as expected?

> 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
>            Assignee: Chetan Mehrotra
>             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)

Mime
View raw message