[jira] [Commented] (OAK-2842) Use mongo op-log to fetch stricter super-set of nodes that changed for a given interval

["Vikas Saurabh (JIRA)" <ji...@apache.org>]

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

Vikas Saurabh commented on OAK-2842:
------------------------------------

I was trying a make-do oplog reading implementation and {{ObservationTest}} results seemed promising -- most notably that even when observation queue reached in hundrends, it dropped down pretty quick.

BUT, then I realized that we are planning to derive op-log's timestamp from revisions -- which might not align well (op-log's time would denote the time when operation on document happened... while revision is created on instance node.. possibly way early than when it'd get persisted into mongo). [~mreutegg], [~chetanm]: I think using op-log won't be a good idea. Thoughts?

> Use mongo op-log to fetch stricter super-set of nodes that changed for a given interval
> ---------------------------------------------------------------------------------------
>
>                 Key: OAK-2842
>                 URL: https://issues.apache.org/jira/browse/OAK-2842
>             Project: Jackrabbit Oak
>          Issue Type: Sub-task
>          Components: core, mongomk
>            Reporter: Vikas Saurabh
>             Fix For: 1.3.0
>
>
> With OAK-2829, we'd have a mechanism inside of oak to have ability to quickly get a set of nodes changed between two root revisions. That collections needs to be managed by Oak itself. Otoh, mongo op-log already does this.
> Opening this task to have implement reading part of such set of nodes (which can possibly be a super set of actual changed nodes) -- considering quite a bit of this part can be re-used in the parent issue where underlying changes are maintained by Oak code.
> As an added advantage, this implementation would avoid writing out/updating changes for mongo specific case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)