FEATURE: Node-Migrations across NodeBased and NodeAggregateBased filters/transformations

[c4ll-m3-j4ck]

Is there an existing issue for this topic?

• I have searched the existing issues

Description

Currently, it is not possible to create a node-migration which selects by a given NodeType and a given PropertyValue. If I try to execute a migration with such an configuration, an error is thrown NodeAggregate Based transformations are only supported without any node based filters. As previously discussed with @dlubitz on slack, I get the difference between a Node and a NodeAggregate, but for integrators, the concept of Aggregates might not make sense and this seems like a rather trivial type of migration to write if you try to clean up NodeTypes in your neos-instance.

I would really like to be able to create migrations that split a given NodeType implementation into multiple discrete NodeTypes to ease our editors experience.

I have added an example of such a migration-config below:

comments: 'Migrate Variants to flexible/sized'
migration:
  - filters:
      - type: 'NodeType'
        settings:
          nodeType: 'Variant'
      - type: 'PropertyValue'
        settings:
          propertyName: 'areaConfigurable'
          serializedValue: true
    transformations:
      - type: 'ChangeNodeType'
        settings:
          newType: 'Variant.Flexible'
  - filters:
      - type: 'NodeType'
        settings:
          nodeType: 'Variant'
      - type: 'PropertyValue'
        settings:
          propertyName: 'areaConfigurable'
          serializedValue: false
    transformations:
      - type: 'ChangeNodeType'
        settings:
          newType: 'Variant.Fixed'

Possible Solution

No response

[nezaniel]

Maybe we can introduce something like an "AggregatePropertyValue" filter for properties that are aggregate scoped.
Background: In Neos 9 it's possible to scope properties. I.e. when a property is declared with scope "nodeAggregate" and is changed in one node, it is kept in sync with all variants of that node (e.g. translations).
In such a case the transformation would be applicable since the property value is now on aggregate level as well. We would have to run a consistency check first, though (since the scope can be changed via configuration after creation of nodes). But it would be definitively doable.

What bothers me more is what happened in Neos 8 and before in this case...

[dlubitz]

What about splitting the node aggregate into two aggregates? And moving /copying the affected nodes of the matching DSPs?

In Neos 8, that simply worked. IIRC if one node matches the filter, regardless of the dimensions, it replaces the nodetype for all nodes.

[nezaniel]

Splitting would be possible, yet non-trivial. Think of links or references pointing to that node that have to be updated to the (partially) new ID.

The described v8 behavior would be a lot easier to implement as we'd just partially ignore the filter

[dlubitz]

@c4ll-m3-j4ck We discussed that topic today in the team and decided to implement as smaller feature in the beginning, which looks reasonable in the implementation and still offer some way of restructure your nodetypes. We also see the need for more advanced migration features here, but in a later phase.

See: #5213