9 Replies Latest reply on Oct 28, 2016 5:54 AM by Horia Chiorean

    Event reporting differences for copy and move operations

    Rustam Usmanov Apprentice

      Having WildFly 10.0.0 and ModeShape 5.2.0 I'm trying to observe events associated with nt:file nodes instantiation during copy and move operations.

      On successful copy operation my listener receives the following events (amongst some others), that I'm interesting in:

      • Node added at /X/Y
      • Property added at /X/Y/jcr:content/jcr:data

      But on successful move operation listener receives only the Node added at /X/Y event (amongst some others). It seems to be in accordance with spec:

      12.2 Scope of Event Reporting

      The scope of event reporting is implementation-dependent. An implementation

      should make a best-effort attempt to report all events, but may exclude events if

      reporting them would be impractical given implementation or resource limitations.

      For example, on an import, move or remove of a subgraph containing a large

      number of items, an implementation may choose to report only events associated

      with the root node of the affected graph and not those for every subitem in the

      structure.

      So what is the reason to not report Property added event for jcr:content/jcr:data when moving nt:file node? Indeed, nt:file doesn't contain a large number of items. The problem I see is that both operations have single outcome - node appeared at /X/Y - but this single outcome is accompanied by different set of crucial events.

        • 1. Re: Event reporting differences for copy and move operations
          Horia Chiorean Master

          Because that's one of the differences between move and copy: copy has to copy the entire subgraph (i.e. create all the nodes in the subgraph at the new location) while move only creates the destination path and doesn't make any changes with respects to the source subgraph.

           

          Also, as per the spec, when moving nodes, a NODE_MOVED event has to be fired to provide information about the previous (source) and current (destination) paths. This is in contrast to the copy operation for which there are no special events.

          • 2. Re: Event reporting differences for copy and move operations
            Rustam Usmanov Apprentice

            move only creates the destination path

            Before the operation there was no a node at destination /X/Y as well as there was no a node at /X/Y/jcr:content. After the operation we can see that node appeared at /X/Y as well as node appeared at /X/Y/jcr:content. So I guess it is the same phenomenon - both nodes changed their state from non-existent to existent at the paths specified. This phenomenon is called "creation". But only for /X/Y! For /X/Y/jcr:content it's called "movement" when operation was move and "creation" for any other operations resulted in instantiation of the node. Sounds strange for me while I'm in a role of an external observer.

             

            and doesn't make any changes with respects to the source subgraph

            After the move operation source subgraph becomes non-existent at the source path. Isn't it a change?

             

            when moving nodes, a NODE_MOVED event has to be fired

            Well, so what's the reason to fire NODE_ADDED for /X/Y if NODE_MOVED provides enough information about changes in workspace?

            • 3. Re: Event reporting differences for copy and move operations
              Horia Chiorean Master

              This phenomenon is called "creation". But only for /X/Y! For /X/Y/jcr:content it's called "movement" when operation was move and "creation" for any other operations resulted in instantiation of the node. Sounds strange for me while I'm in a role of an external observer.

              It's not necessarily called "creation". It can also be called linking and unlinking. creation is creating new nodes in the repository; linking and unlinking is changing the root of a subgraph.

              when moving nodes, a NODE_MOVED event has to be fired

              Well, so what's the reason to fire NODE_ADDED for /X/Y if NODE_MOVED provides enough information about changes in workspace?

              I was pointing out that as per spec, NODE_MOVED is a special event, created only for the move operation. I didn't say this was the only event or that it contained enough information for all/whatever use case.

               

              In conclusion, IMO the current behavior does not contradict the spec in any way.

              • 4. Re: Event reporting differences for copy and move operations
                Rustam Usmanov Apprentice

                It's not necessarily called "creation".

                OK. Let's call it "node addition and movement" since observer received NODE_ADDED and NODE_MOVED events as regards destination path.

                There was no node at destination path /X/Y, then node appears here and this is considered a change in workspace and at least two events fired indicating this change.

                There was no node at destination path /X/Y/jcr:content, then node appears here and this is not considered a change in workspace since no events corresponding to this path fired.

                Also there was no property at destination path /X/Y/jcr:content/jcr:data, then property appears here and this is not considered a change in workspace since no events corresponding to this path fired.

                It seems that remapping of Y/jcr:content from source to destination path is a change in workspace. And this change should be reported. No? Why?

                I didn't say this was the only event or that it contained enough information for all/whatever use case.

                Tell me, please, what additional information could be received from NODE_ADDED at /X/Y and NODE_REMOVED at /Z/Y events when NODE_MOVED from /Z/Y to /X/Y event is already received?

                • 5. Re: Event reporting differences for copy and move operations
                  Horia Chiorean Master

                  Moving is internally implemented differently than copying. That's why when moving only the destination path (if it does not exist) is reported as NODE_ADDED, unlike copy where for each of nodes from the subgraph is created anew and therefore a NODE_ADDED event if fired for each. NODE_ADDED events are reported by ModeShape atm. *only* for newly created nodes and properties, plain and simple.

                   

                  As you point out in the first post, as per 12.2 Scope of Event Reporting this is perfectly acceptable and it's how the implementation works.

                   

                  If you'd like more NODE_ADDED events to be fired for move, feel free to suggest an enhancement patch which we can evaluate. You should be aware however that this is a highly complex change which would also affect the indexing behavior which currently handles NODE_MOVED events.

                  • 6. Re: Event reporting differences for copy and move operations
                    Rustam Usmanov Apprentice

                    Yes, I understood that behaviour described above is a result of a specific move operation implementation in ModeShape. Before suggesting an enhancement I'm trying to justify it. If I'm claiming that there are not enough (not at all) events for subgraph nodes and properties, in the first place I should ensure that subgraph remapping to destination path should be considered a change to workspace from the observer's point of view. So I'm asking this question here hopefully to receive a clear answer - yes or no.

                    • 7. Re: Event reporting differences for copy and move operations
                      Horia Chiorean Master

                      The JCR spec I ambiguous as to what NODE_ADDED means:

                         /**

                           * Generated on persist when a node is added. <ul> <li>{@link #getPath}

                           * returns the absolute path of the node that was added.</li> <li>{@link

                           * #getIdentifier} returns the identifier of the node that was added.</li>

                           * <li>{@link #getInfo} returns an empty <code>Map</code> object.</li>

                           * </ul>

                           */

                      ModeShape interprets this as: a new node is created and persisted; your case suggests another behavior. So personally I do not agree with the interpretation that NODE_ADDED events should be fired when moving hierarchies.

                      • 8. Re: Event reporting differences for copy and move operations
                        Rustam Usmanov Apprentice

                        Not so fast, please. You ran ahead slightly .

                        My questionnaire is:

                        1. Is subgraph remapping to destination path considered a change or a set of changes to workspace?

                        2. If yes, then should be this change reported as event? No, if it's impractical or resource exhaustive.

                        3. If yes, as which event(s) should it be reported?

                        Yes, I agree that NODE_ADDED shouldn't be fired when moving hierarchies. Moreover it should be so for the root node being moved. What about NODE_MOVED for subgraph nodes?

                        • 9. Re: Event reporting differences for copy and move operations
                          Horia Chiorean Master

                          Please take up 1-3 with the authors of the JCR spec. IMO the current ModeShape implementation matches what's in the JSR 283 spec and such, the current behavior is perfectly ok. Anything else is debating semantics about the specification which I'm not interested in doing.

                          Moreover it should be so for the root node being moved. What about NODE_MOVED for subgraph nodes?

                          No. The spec is clear about the fact the NODE_MOVED should be fired once per move operation and should contain information about the top-most level of the graph - i.e. the parameters of the move method. Moreover, the TCK tests validate this behavior.