-
-
Notifications
You must be signed in to change notification settings - Fork 224
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
BUG: 9.0 - Translating document nodes leads to wrong ordering #4742
Comments
FYI: I can't detect any issues with only CreateNodeAggregateWithNode alone, which commands are needed for this to fail? |
the content graph part will be fixed in #4961 |
follow-up is ready: #4975 |
Also: NodeSpecializationVariantWasCreated needed to be adjusted for edge cases where a succeeding sibling is deleted in a variant that is to be created by variation. |
BUGFIX: #4742 - Interdimensional relatives
Currently the ordering behavior of the CR is undefined for the following scenarios:
This leads to the problem that different projections implement ordering differently then; leading to subtle bugs.
For instance, the
DocumentUriPathProjection
needs the ordering as well to find the first child node for FirstChild-shortcuts -- and it currently does it differently than the Content Graph.That is what I originally wanted to fix; when I stumbled into this rabbit hole ;)
Current Behavior
On the demo site, let's say you have the following english nodes:
=> now, you translate
b
to german; leading to the following structure:=> now, you translate
a
to german, leading to the following structure:=> this is wrong, expected would be:
Fixing Plan
PositionMapping
(modeled afterMoveNodeMapping
)NOTE: NodeSpecializationVariantWasCreated does not need to be adjusted, because it only leads to re-wiring of edges, and not to new edges.
The text was updated successfully, but these errors were encountered: