TASK: Constraint ESCR dimension space point migrations #5514
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…can contain changes and are rebase-able
|
I am confused now, shouldn't this be a failing test? |
…nterface` and `NodeAggregateBasedTransformationInterface`
…o work for command steps The PR neos#5361 simplified everything into a simple ``` @when the command :shortCommandName is executed with payload: ``` step which does not provide autocompletion when writing new tests or also allows to find usages of exactly that step which speeds up filling out the required payload
…n other workspaces
…ild nodes recursively for removed dimension space points
… new specialisations for existing generalisations
This task belongs to the `AddDimensionShineThrough` command and must be run first. Using `UpdateRootNodeAggregateDimensions` would only add that dimension to the root node without any fallback which is wrong!
As shown by test 'Run migration after renaming a new dimension value'
> Cannot add fallback dimensions via update root node aggregate because node lady-eleonode-rootford already covers generalisations [{"language":"mul"}]
… generalisation where specialisation still falls-back to nodes
If we would drop the eges of a generalisation like "de" all fallback node rows would still be connected via the specialisation ("gsw") hierarchy edges but state that their occupation is "de".
This is the nature when dropping edges but not updating the node rows first.
Thus we must ensure that ALL variants must be varied first. Eg "./flow content:createvariantsrecursively" see test.
…emoved` events for root node in special dimension instead of doing so explicitly
…ubtree-tags-on-root-node-aggregate' into taks/constraint-dimension-structure-adjusments
…g dimensions its ensured by a previous `NodeAggregateWasRemoved` that `RootNodeAggregateDimensionsWereUpdated` only signals that dimensions are ADDED.
Also mark empty dimensions as affected source, but that will be removed wither way with: neos#5516 because its wrong.
6 tasks
…ishableChanges` together
…ishableChanges` together
…orkspaces (e.g. migration-ws based on live) This enables us to do meaningful constraint checks versus changes in other workspaces. https://neos-project.slack.com/archives/C04PYL8H3/p1741976899524389
… checks and not.
otherwise dimensions that are about to be removed still could contain changes.
- nodes can never be created if the parent doenst cover them, this is an invariant - the update root node aggregate constraint checks prevent creating a spezi
to allow executing multiple migrations on a workspace
6 tasks
…n as this cannot be published either way and must never occur on a user workspace see InvalidDimensionAdjustmentTargetWorkspace
Workspace migration-cs must be root workspace or target a root workspace.
…kspace simultaneously
…only be executed once
nezaniel
requested review from
dlubitz,
bwaidelich and
kitsunet
and removed request for
dlubitz and
bwaidelich
|
ok but, like, as we discussed:
Seems like an unrealistic requirement in any real world scenario? |
well, for one, this is not a new requirement (it states the same in the documentation), it is now only enforced to prevent conflicts in workspaces that are hard to resolve (mostly by discard). |
kitsunet
approved these changes
Mar 23, 2025
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A shallow look into the new dimension space point migrations reveals a (obvious) problem:
When
MoveDimensionSpacePointis run live or anywhere else, workspace will not be able to publish pending changes to live or rebase anymore because all the rebased commands will target the original dimensions which no longer exist according to the variation graph:The documentation recommends https://docs.neos.io/guide/content-repository/content-dimensions/migrating-dimension-config
Though this is not enforced via constraint checks.
The new node migrations sometimes warranted for new commands and events because otherwise things would be impossible.
New command and events, that where introduce for that use-case:
introduced via: neos/contentrepository-development-collection#177
AddDimensionShineThrough-> emitsDimensionShineThroughWasAddedMoveDimensionSpacePoint-> emitsDimensionSpacePointWasMovedintroduced via: #4093
UpdateRootNodeAggregateDimensions-> emitsRootNodeAggregateDimensionsWereUpdatedThis PR changes the described behavior by adding further restrictions and the respective tests:
MoveDimensionSpacePointandUpdateRootNodeAggregateDimensionsadjustments can no longer be run if there are any changes in any other workspace than the one they are applied toMoveDimensionSpacePointandUpdateRootNodeAggregateDimensionsnow fail if there are any fallbacks active that would become invalid after or removed by the changeIt also contains smaller necessary fixes and adjustments:
Upgrade instructions
none
Review instructions
See introduction
Checklist
FEATURE|TASK|BUGFIX!!!and have upgrade-instructions