You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2014/02/24 15:39:20 UTC

[jira] [Assigned] (OAK-1459) Many extra events are dispatched from a move event

     [ https://issues.apache.org/jira/browse/OAK-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig reassigned OAK-1459:
----------------------------------

    Assignee: Michael Dürig

> Many extra events are dispatched from a move event
> --------------------------------------------------
>
>                 Key: OAK-1459
>                 URL: https://issues.apache.org/jira/browse/OAK-1459
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: jcr
>            Reporter: Will McGauley
>            Assignee: Michael Dürig
>             Fix For: 1.0
>
>
> When moving a node many extra events are dispatched in OAK in compared to other implementations
> On Oak a node added and node remove events are dispatched for each node in the hierarchy being moved.  As well there is a property add and property remove event dispatched for each property in the node hierarchy.  
> This compares to previous implementations where only a Node Moved, node added and node removed event is dispatched for the parentnode being moved.
> See [0] for an example.
> For me this is problematic for a couple of reasons:
> 1) We are dispatching more events than we did previously.  In cases where nodes are frequently moved this will add extra load on the system. 
> 2) It is becoming increasingly difficult to ignore events related to a move without spending extra cycles to make that determination. 
> 3) Many pre-existing event listeners will be executing on events that they previously would not have.
> I know the JCR spec indicates that an implementation may choose to dispatch these events or not, but I suggest we change OAK to not throw these extra events.  If we do not many observation listeners will act on events they previously did not will likely cause problems.
> Also, if we could add a simple marker in any event’s info map which is related to a node move (ie: the node removed, node added etc) it would be very helpful when trying to ignore events caused by a move.  (which I believe to be the case in many situations).
> [0] 
> Move “c” in the hierarchy below from /a/b to /a/z:
> /a/b/c/d/e
> to:
> /a/z/c/d/e
> Results in:
> CRX2:
> /a/b, type: {node removed}
> /a/z/b, type: {node added}
> /a/z/b, type: {node moved}
> OAK:
> /a/b/c, type: {node removed}
> /a/z/c, type: {node moved}
> /a/z/c, type: {node added}
> /a/b/c/jcr:primaryType, type: {property removed}
> /a/b/c/jcr:createdBy, type: {property removed}
> /a/b/c/jcr:created, type: {property removed}
> /a/b/c/d, type: {node removed}
> /a/z/c/jcr:primaryType, type: {property added}
> /a/z/c/jcr:createdBy, type: {property added}
> /a/z/c/jcr:created, type: {property added}
> /a/z/c/d, type: {node added}
> /a/b/c/d/jcr:primaryType, type: {property removed}
> /a/b/c/d/jcr:createdBy, type: {property removed}
> /a/b/c/d/jcr:created, type: {property removed}
> /a/b/c/d/e, type: {node removed}
> /a/z/c/d/jcr:primaryType, type: {property added}
> /a/z/c/d/jcr:createdBy, type: {property added}
> /a/z/c/d/jcr:created, type: {property added}
> /a/z/c/d/e, type: {node added}
> /a/b/c/d/e/jcr:primaryType, type: {property removed}
> /a/b/c/d/e/jcr:createdBy, type: {property removed}
> /a/b/c/d/e/jcr:created, type: {property removed}
> /a/z/c/d/e/jcr:primaryType, type: {property added}
> /a/z/c/d/e/jcr:createdBy, type: {property added}
> /a/z/c/d/e/jcr:created, type: {property added}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)