As part of work on migration diffs, it occurred that some upgrade tasks — those that have been implemented as QueryTasks, are very likely to cause incomplete upgrade issues.
1. In particular, this is the case when a module has a first delta that creates/modifies a node structure, and then a second delta which executes a QueryTask. There is no guarantee at all that the query returns non-persisted changes in that workspace.
- just as stated in the JCR spec:
- implementations may or may NOT account for pending changes in the current session
- see http://www.day.com/maven/jcr/2.0/6_Query.html#6.5%20Search%20Scope.
- even the QueryTask javadoc itself mentions it.
2. We don't save sessions between deltas, only between modules.
Lights, Camera, Action!
1. We introduce a NodeVisitorTask, which in a similar fashion as the QueryTask enables to specify matching criteria and #operateOnNode().
- We call for replacing QueryTask implementations with it.
2. We make it way more explicit that the QueryTask can only operate safely on persisted content.
- We log a warning whenever executing a QueryTask.
- In 5.4 we deprecate current constructor, and add a new one with a boolean flag in the following spirit: "I read about the limitations and I know what I'm doing". If that boolean is false (default), we will fire a TaskExecutionException and interrupt the upgrade (see followup ticket MAGNOLIA-5859).