[MAGNOLIA-3704] versioning: clean mgnlVersions workspace after versioning Created: 20/May/11 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | activation, core |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Philipp Bärfuss | 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: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Date of First Response: | |||||||||||||
| Description |
|
When we version we clone the node and its children to mgnlVersions based on rules. We clone paragraphs together with the page but not the subpages. If this rules are not applied consequently then it can happen that a node we are activating/versioning already exists as a subnode of another node and then the process fails. We had several issues related to the DMS with this but currently again in the Data module ( Since this nodes are just handles to the version history after we versioned the content, we could simply purge all content of the node after the versioning. |
| Comments |
| Comment by Philipp Bärfuss [ 23/May/11 ] |
|
This won't solve the issue when you first activate the child and then the parent. The child clone with it's uuid will already exist in the root when we try to clone the parent (including its children). |
| Comment by Jan Haderka [ 23/May/11 ] |
|
so the solution should be to purge all nonversionable content and when versioning check for existence of the uuid and move the node to proper location when found before reimporting the content for versioning |
| Comment by Philipp Bärfuss [ 23/May/11 ] |
|
not so sure because we had to move it back to the root later to not keep it's version history |
| Comment by Jan Haderka [ 23/May/11 ] |
|
why not to keep all items with mix:versionable in the root then by default? With JR 2.2 b-tree manager there should be no performance penalty for that. and we could safely purge all the children w/o risk of loosing history ... maybe time to create concept for this and discuss details there. |
| Comment by Philipp Bärfuss [ 24/May/11 ] |
|
I agree that it is the right moment to write a concept. In Magnolia 5 we wanted to get completely rid of this special workspace and the cloning. If we version directly on the original node we wont have that problem as one can version sub nodes at any time. Perhaps we should simply fix |
| 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. |