-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE: Node-Migrations across NodeBased and NodeAggregateBased filters/transformations #5190
Comments
Maybe we can introduce something like an "AggregatePropertyValue" filter for properties that are aggregate scoped. What bothers me more is what happened in Neos 8 and before in this case... |
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. |
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 |
@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 |
Is there an existing issue for this topic?
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:
Possible Solution
No response
The text was updated successfully, but these errors were encountered: