[
https://issues.apache.org/jira/browse/OAK-3680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972189#comment-15972189
]
Marcel Reutegger commented on OAK-3680:
---------------------------------------
No, in this particular case, looking at the node at T1 after the RevisionGC
either gives you:
- {{foo=bar}}, when the node state was computed before the RevisionGC and is
served from the cache.
- A node that doesn't have a {{foo}} property, when the node state is created
based on the current document. {{foo=bar2}} is newer than T1 and therefore not
visible at that revision.
In general, I would say the behaviour is currently undefined when you read a
state older than the most recent revision GC timestamp. Oak should therefore
not depend on any such behaviour and always use checkpoints when it needs to
read a repository state at some point later. This isn't really a good
definition, but basically anything that goes beyond the MVCC usage during
regular commit processing.
Btw, I would actually prefer an implementation that doesn't allow reads that
are older then the most recent revision GC timestamp.
> Partial re-index from last known good state
> -------------------------------------------
>
> Key: OAK-3680
> URL: https://issues.apache.org/jira/browse/OAK-3680
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: indexing, lucene
> Affects Versions: 1.0, 1.2
> Reporter: Michael Marth
> Assignee: Chetan Mehrotra
> Labels: resilience
> Fix For: 1.8
>
>
> ATM indexes break (by whatever circumstances) users need to perform a full
> re-index. Depending on the size off the repository this can take a long time.
> If the user knows that the indexes were in a good state at a certain revision
> in the past then it would be very useful, if the user could trigger a
> "partial" re-index where only the content added after a certain revision was
> updated in the index.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
