[
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
