Update mechanism improvements
(MAGNOLIA-5529)
|
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | updatemechanism |
| Affects Version/s: | 5.2.2 |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Major |
| Reporter: | Roman Kovařík | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | maintenance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
Some of delta tasks doesn't fail with TaskExecutionException but e.g. with NPE. |
| Comments |
| Comment by Daniel Lipp [ 21/Feb/14 ] |
|
I'm not convinced here. There's surely cases where it's not a prob when a certain Property or Node is not around. But then there's also the other cases where this is very relevant. So for most of the tasks we need the option to execute in both modes. With the current impl. we can do that, but obviously our default is the strict mode - if you want it to be more tolerant, you have to nest into a conditional task. Changing the default to be tolerant is very dangerous: it would become less likely to spot differences and hence potential problems. |
| Comment by Magnolia International [ 21/Feb/14 ] |
|
Updates should be written carefully. The repo needs to be in a definite state. You know exactly which version you're upgrading from, so you should know what's there and not there. If a given node or property is gone, it means either you're not in the state you thought you were, or the user has made some (configuration) change, which the update task should take into account. Most cases I've seen where ConditionalTasks were heavily used were cases where we weren't sure what we upgrading from, and/or added the task "too late" (forgot to add this one in 1.2.3, so we add it in 1.2.5, which then has to take into account that the module was perhaps only ever installed from 1.2.4, where the property is already gone). One thing that seems to have escaped a lot of people's mind is that you can (you should!) write your own task classes. I've seen cluttered MVHs because they add clusters and clusters of Conditional(PropertySet) and the like, each with their (ignored because after writing 3, one has better things to do) names and descriptions that would have highly benefitted from a rather simple but custom Task implementation. |
| Comment by Laura Delnevo [ 02/Oct/23 ] |
|
Hello, This ticket is now marked as closed due to one of the following reasons:
If you are still facing a problem or consider this issue still relevant, please feel free to re-open the ticket and we will reach out to you. Thank you, The Magnolia Team |