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

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

    Fix Version/s: 1.0

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

Reply via email to