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/25 22:01:20 UTC
[jira] [Resolved] (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 resolved OAK-1459.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.0)
0.18
Fixed at http://svn.apache.org/r1571751
> 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: 0.18
>
>
> 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)