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 "Will McGauley (JIRA)" <ji...@apache.org> on 2014/02/21 15:12:22 UTC

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

Will McGauley created OAK-1459:
----------------------------------

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


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)