Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-1459

Many extra events are dispatched from a move event

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.18
    • Component/s: jcr
    • Labels:

      Description

      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}

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                mduerig Michael Dürig
                Reporter:
                wmcgaule Will McGauley
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: