-
1. Re: Event reporting differences for copy and move operations
hchiorean Oct 27, 2016 2:21 AM (in response to zcc39r)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
zcc39r Oct 27, 2016 3:43 AM (in response to hchiorean)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
hchiorean Oct 27, 2016 7:32 AM (in response to zcc39r)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
zcc39r Oct 28, 2016 3:22 AM (in response to hchiorean)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
hchiorean Oct 28, 2016 3:36 AM (in response to zcc39r)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
zcc39r Oct 28, 2016 4:13 AM (in response to hchiorean)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
hchiorean Oct 28, 2016 4:24 AM (in response to zcc39r)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
zcc39r Oct 28, 2016 5:25 AM (in response to hchiorean)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
hchiorean Oct 28, 2016 5:54 AM (in response to zcc39r)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.