Update mechanism improvements (MAGNOLIA-5529)

[MAGNOLIA-5683] Delta tasks should fail gracefully Created: 14/Feb/14  Updated: 02/Oct/23  Resolved: 02/Oct/23

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:
supersession
supersedes MAGNOLIA-5704 NewPropertyTask fails with NPE if nod... Closed
Template:
Date of First Response:

 Description   

Some of delta tasks doesn't fail with TaskExecutionException but e.g. with NPE.
Delta tasks should fail gracefully or not fail if it doesn't make sense (Remove*Task, ...). This behaviour forces us to wrap them into conditional tasks which makes version handler cluttering and makes it difficult to use them.
Add unit tests for common delta task to test their failure behaviour.



 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: 

  • A long period of inactivity 
  • Uses an old or Beta version of an application, module, or framework that we no longer support 
  • The issue is no longer reproducible or has been fixed in later versions 

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

Generated at Mon Feb 12 04:07:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.