jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tommaso Teofili (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-153) Split the CommitHook interface
Date Tue, 26 Jun 2012 14:25:42 GMT

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

Tommaso Teofili commented on OAK-153:
-------------------------------------

bq. Background: I could imagine an implementation where beforeCommit and afterCommit cooperate
in that the final afterCommit might be interested in stuff done for beforeCommit. Depending
on how the classes are instantiated this might be simple or not.

I think splitting the interface shouldn't hurt such a use case (e.g. ClassY implements CommitEditor,
Observer) while the current interface forces to have both even if, for example, the CommitHook
is just useful for doing post commit operations (e.g. indexing/persisting stuff on some external/different
storage). In that case the #beforeCommit could often be:
{code}
    @Override
    public NodeState beforeCommit(NodeStore store, NodeState before, NodeState after) throws
CommitFailedException {
        // doesn't do anything during the pre commit phase
        return after;
    }
{code}
My 2 cents here (quite new to Oak).
                
> Split the CommitHook interface
> ------------------------------
>
>                 Key: OAK-153
>                 URL: https://issues.apache.org/jira/browse/OAK-153
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>
> The {{CommitHook}} interface has two methods, {{beforeCommit()}} and {{afterCommit()}},
since the symmetry originally seemed like a good idea. However, in practice these methods
are not really so symmetric after all.
> For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end up being
called multiple times for a given changeset if it needs to be repeatedly rebased or otherwise
revised before it can be committed. There isn't even any guarantee that a particular changeset
on which {{beforeCommit()}} has been called ever gets committed. And on the other hand there
are good reasons to avoid calling {{afterCommit()}} on each and every commit that has been
made. Instead it could be called only every now and then to cover larger sets of changes.
> Thus I'd like to split the {{CommitHook}} interface to two parts that I'd tentatively
call {{CommitEditor}} and {{Observer}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message