-
Improvement
-
Resolution: Fixed
-
Major
-
5.3.1
Background
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).
- causes
-
MAGNOLIA-8255 QueryTask warning might be more subtle
- Open
- is cloned by
-
MAGNOLIA-5859 Further prevent unsafe usages of QueryTask
- Closed
- is depended upon by
-
MAGNOLIA-2595 Update tasks : streamline class names, functionality and provide a couple more useful abstractions
- Closed
-
MGNLDATA-257 Cannot start companyApp after update from Magnolia 4.5.19
- Closed
-
MGNLDATA-261 Migration diffs when migrating from 4.5 to 5.2.x
- Closed