[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:
dependency
is depended upon by MGNLDATA-124 activation of hierarchical data fails Closed
relation
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 (MGNLDATA-124).

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.
There's also another article here about the said manager.

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 MGNLDATA-124 by ensuring that the rules are setup correctly for the hierarchical types.

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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 03:48:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.