[MAGNOLIA-6492] Migration from 4.5 to 5.3 is failing due to ConvertMetaDataUpdateTask Created: 11/Jan/16  Updated: 19/May/22  Resolved: 19/May/22

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 5.3.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Eric Hechinger Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: affect-vn-project
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

If a 4.5 project defines additional repository (shared for example) and a a custom node type that defines the MetaData child node as mandatory, the 5.0 core version handler task will failed.

Reason:
In CoreModuleVersionHandler

        register(DeltaBuilder.update("5.0", "")
...
                .addTask(new RemoveMetaDataInNodeTypeDefinitionTask("Un register the metaData child node", "", RepositoryConstants.CONFIG))
                .addTask(new ConvertMetaDataUpdateTask("Convert MetaData Task", "Remove the metaData sub node and replace them with mixIn when appropriate"))
  • RemoveMetaDataInNodeTypeDefinitionTask : will remove the MetaData child node definition for the main magnolia repository and not in the shared one.
  • ConvertMetaDataUpdateTask: will remove the child MetaData node and set properties to the parent node, but for all the repositories.


 Comments   
Comment by Jan Haderka [ 11/Jan/16 ]

I would argue that no custom type should define our MetaData child node as mandatory, or if they did, it's the problem of their definition and expiation of the code and should be fixed as pre-migration step.

Comment by Eric Hechinger [ 11/Jan/16 ]

I will keep the pre-migration step approach.
We did additional test and it appears that RemoveMetaDataInNodeTypeDefinitionTask removed correctly the Metadata child node definition for the magnolia repository and all associated workspaces.
Our issue is due to the fact that this node type is defined in another shared repository....

In addition they have defined the following node type:

	<nodeType hasOrderableChildNodes="true" isAbstract="false" isMixin="false" isQueryable="true" name="loanOrigination" primaryItemName="">
		<supertypes>
			<supertype>dataItem</supertype>
		</supertypes>
	</nodeType>
...
	<nodeType name="dataItem" isMixin="false" hasOrderableChildNodes="true" primaryItemName="">
		<supertypes>
			<supertype>dataItemBase</supertype>
		</supertypes>
		<childNodeDefinition name="MetaData" defaultPrimaryType="mgnl:metaData" autoCreated="true" mandatory="true" onParentVersion="COPY" protected="false" sameNameSiblings="false">
			<requiredPrimaryTypes>
				<requiredPrimaryType>mgnl:metaData</requiredPrimaryType>
			</requiredPrimaryTypes>
		</childNodeDefinition>
	</nodeType>

dataItem is a 4.5 Magnolia node type definition.

Comment by Roman Kovařík [ 19/May/22 ]

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:15:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.