BUGFIX: Find child node aggregate with multiple parents #5489
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
…ct coverage With a join on ph was removed which was previously also not used: neos#5268 Now the join is reintroduced and used to determine the covereddimensionspacepoint
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.
While working #5480 i also wanted to test the child node aggregates query.
Now it seems it was also optimised by #5268 to remove a join which was really not used!.
But i found that the query has problems with multiple parents in multiple dimensions.
Now moving b only in the specialisation to a from home and querying all childnodes of a, will only result the node row b from the specialisation to be queried.
But to build the whole node aggregate we need also the noderow where b is in the source dimension.
Now it seems that the intention of find child node aggregates and the node aggregate itself contradict. As when being interested in children from a, well the node row b is only that for the specialisation.
A node aggregate should in my opinion be node a question from the perspective of how it was retrieved but should always contain the same node rows - as find by id would return.
Either we introduce a new object here to only really shown the affected node rows or attempt to fix the original query which i did - but im not sure if that is correct yet. Thought the test says yes.
@kitsunet and @dlubitz also discussed it might be worth to just return the node identifiers and have a separate query to turn them into aggregates or let the node factory do that.
Upgrade instructions
Review instructions
Checklist
FEATURE|TASK|BUGFIX!!!and have upgrade-instructions