Update mechanism improvements
(MAGNOLIA-5529)
|
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | updatemechanism |
| Affects Version/s: | 3.5 RC3 |
| Fix Version/s: | None |
| Type: | Sub-task | Priority: | Major |
| Reporter: | Vivian Steller | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
It is a very common use case that when bootstrapping content during update one would like to backup an already existing node. It would be nice if one could just pass a backupBeforeBootstrap boolean flag that indicates if the existing nodes shall be kept in a backup location. |
| Comments |
| Comment by Vivian Steller [ 10/Dec/07 ] |
|
We might want to use the BackupTask to perform the backup: see |
| Comment by Vivian Steller [ 10/Dec/07 ] |
|
we first should refactor the whole bootstrap mechanism (see |
| Comment by Vivian Steller [ 11/Dec/07 ] |
|
resolving this we also can fix the TODO in WorkflowModuleVersionHandler (r13511, line 90). |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |