[
https://issues.apache.org/jira/browse/OAK-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882552#comment-15882552
]
Andrei Dulceanu edited comment on OAK-5753 at 2/24/17 12:25 PM:
----------------------------------------------------------------
bq. Would it be helpful to also log the timestamp along with the revisions?
+1, I think this adds value, especially for multiple check results (as the one
you provided).
bq. This would need an improvement for the {{JournalReader}} first, but since
we now have the timestamps in the journal that additional information might be
helpful.
Quickly browsing through issues, I found this comment [1] you made a while ago.
Is it still applicable? Not sure if I got it right, but iterating over a
{{<String, Long>}} tuple in {{JournalReader}} will not be possible for older
journals and will break compatibility. Of course, we can make some tweaks to
return {{null}} when the timestamp is not present in the journal, but I wanted
to ask this question in order not to unnecessarily complicate the code in
{{JournalReader}}.
[1]
https://issues.apache.org/jira/browse/OAK-4095?focusedCommentId=15221468&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15221468
was (Author: dulceanu):
bq. Would it be helpful to also log the timestamp along with the revisions?
+1, I think this adds value, especially for multiple check results (as the one
you provided).
bq. This would need an improvement for the {{JournalReader}} first, but since
we now have the timestamps in the journal that additional information might be
helpful.
Quickly browsing through issues, I found this comment [1] you made a while ago.
Is it still applicable? Not sure if I got it right, but iterating over a
{{<String, Long>}} tuple in {{JournalReader}} will not be possible for older
journals and will break compatibility.
[1]
https://issues.apache.org/jira/browse/OAK-4095?focusedCommentId=15221468&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15221468
> Consistency check incorrectly fails for broken partial paths
> -------------------------------------------------------------
>
> Key: OAK-5753
> URL: https://issues.apache.org/jira/browse/OAK-5753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run, segment-tar
> Affects Versions: 1.8
> Reporter: Andrei Dulceanu
> Assignee: Andrei Dulceanu
> Labels: tooling
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-5753.patch
>
>
> To better explain the bug I'll describe the content of the revisions:
> # Valid Revision
> Adds child nodes {{a}}, {{b}}, {{c}}, {{d}}, {{e}}, {{f}} with various
> properties (blobs included)
> # Invalid Revision
> Adds child node {{z}} with some blob properties and then corrupts the
> {{NODE}} record holding {{z}}.
> Now when the consistency check is run, it correctly detects that the second
> revision is broken, *marks the path {{/z}} as corrupt* and then continues
> checking the first valid revision. Because of a check introduced for OAK-5556
> [1], which tries to validate the user provided absolute paths before checking
> them, the checker tries to check {{/z}} in the first revision, where of
> course it can't find it. Therefore the check incorrectly fails for this
> revision, although it shouldn't have to.
> /cc [~mduerig], [~frm]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
