You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2012/07/19 16:57:33 UTC

[jira] [Created] (OAK-197) oak-api ConflictHandler defines method using oak.spi.state.NodeState

angela created OAK-197:
--------------------------

             Summary: oak-api ConflictHandler defines method using oak.spi.state.NodeState
                 Key: OAK-197
                 URL: https://issues.apache.org/jira/browse/OAK-197
             Project: Jackrabbit Oak
          Issue Type: Bug
          Components: core
            Reporter: angela


similar issue than was reported in OAK-191:

IMO the current ConflictHandler interface defined in the oak-api mixes 
different levels of abstraction by defining methods that refer both 
to Tree and NodeState. in particular because the latter is defined
in the oak.spi.state package which IMO should not be exposed on the
oak-api level.

the methods i am referring to are:

    Resolution addExistingNode(Tree parent, String name, NodeState ours, NodeState theirs);
    Resolution changeDeletedNode(Tree parent, String name, NodeState ours);
    Resolution deleteChangedNode(Tree parent, String name, NodeState theirs);
    Resolution deleteDeletedNode(Tree parent, String name);

wouldn't it be better to use Tree instead of NodeState?
if that's not feasible i would either argue that the inteface doesn't belong 
to the oak-api or that the distinction between Tree and NodeState is artificial
and we should try to get rid of it.


--
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

        

[jira] [Commented] (OAK-197) oak-api ConflictHandler defines method using oak.spi.state.NodeState

Posted by "Michael Dürig (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OAK-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421369#comment-13421369 ] 

Michael Dürig commented on OAK-197:
-----------------------------------

Since {{Tree}}s are mutable data structures I think its wrong to have them as arguments to those methods in place of the currently used {{NodeState}}s. 

Instead of changing the signatures of the methods in {{ConflictHandler}} I think we should rather remove {{ConflictHandler}} from the Oak API and make it a plugin somewhere in the SPI space. 
                
> oak-api ConflictHandler defines method using oak.spi.state.NodeState
> --------------------------------------------------------------------
>
>                 Key: OAK-197
>                 URL: https://issues.apache.org/jira/browse/OAK-197
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: core
>            Reporter: angela
>
> similar issue than was reported in OAK-191:
> IMO the current ConflictHandler interface defined in the oak-api mixes 
> different levels of abstraction by defining methods that refer both 
> to Tree and NodeState. in particular because the latter is defined
> in the oak.spi.state package which IMO should not be exposed on the
> oak-api level.
> the methods i am referring to are:
>     Resolution addExistingNode(Tree parent, String name, NodeState ours, NodeState theirs);
>     Resolution changeDeletedNode(Tree parent, String name, NodeState ours);
>     Resolution deleteChangedNode(Tree parent, String name, NodeState theirs);
>     Resolution deleteDeletedNode(Tree parent, String name);
> wouldn't it be better to use Tree instead of NodeState?
> if that's not feasible i would either argue that the inteface doesn't belong 
> to the oak-api or that the distinction between Tree and NodeState is artificial
> and we should try to get rid of it.

--
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