-
-
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
TASK: Verify and optimize FlowQuery operations #4699
Conversation
…ifyAndOptimizeFlowQuery # Conflicts: # Neos.Neos/Documentation/References/CommandReference.rst # Neos.Neos/Documentation/References/EelHelpersReference.rst # Neos.Neos/Documentation/References/FlowQueryOperationReference.rst # Neos.Neos/Documentation/References/Signals/ContentRepository.rst # Neos.Neos/Documentation/References/Signals/Flow.rst # Neos.Neos/Documentation/References/Signals/Media.rst # Neos.Neos/Documentation/References/Signals/Neos.rst # Neos.Neos/Documentation/References/Validators/Flow.rst # Neos.Neos/Documentation/References/Validators/Media.rst # Neos.Neos/Documentation/References/Validators/Party.rst # Neos.Neos/Documentation/References/ViewHelpers/ContentRepository.rst # Neos.Neos/Documentation/References/ViewHelpers/FluidAdaptor.rst # Neos.Neos/Documentation/References/ViewHelpers/Form.rst # Neos.Neos/Documentation/References/ViewHelpers/Fusion.rst # Neos.Neos/Documentation/References/ViewHelpers/Media.rst # Neos.Neos/Documentation/References/ViewHelpers/Neos.rst # Neos.Neos/Documentation/References/ViewHelpers/TYPO3Fluid.rst
…ifyAndOptimizeFlowQuery # Conflicts: # Neos.Neos/Tests/Behavior/Features/Fusion/FlowQuery.feature
… `Prev`, `PrevAll` In addition: - `Nodes::last` method is added - `Nodes::until` is removed because of broken semantic. BetterAlternatives are `previousAll` and `nextAll` - `NodeNameFactory::forRoot` is added - `Nodes::isEmpty` add assertions that `first` and `last` will return not null
4940424
to
37d901e
Compare
Fyi to why |
Neos.ContentRepository.Core/Classes/Projection/ContentGraph/Nodes.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Projection/ContentGraph/Nodes.php
Outdated
Show resolved
Hide resolved
thanks for taking care. It looks quite logical and way more performant ^^. I like to wait for #4695 to be upmerged so we easier review the tests. |
…ifyAndOptimizeFlowQuery # Conflicts: # Neos.Neos/Tests/Behavior/Features/Fusion/FlowQuery.feature
…er expectation of type filter
Co-authored-by: Marc Henry Schultz <85400359+mhsdesign@users.noreply.github.com>
@mhsdesign if you look into the commits you will find that this pr contains the upmerge of #4695 and #4702 (follow up) you can compare the test cases by checking out the pr and use compare branches on the feature file to see the differences. |
I suggest to look into the |
# @todo Decide wether the changed order of the results compared to Neos 8.3 is ok | ||
# Result in Neos 8.3: "typeFilter: a1a,a1b1a,a1a2,a1b2,a1a3,a1a4,a1a5,a1a6" | ||
# Result in Neos 9.0: "typeFilter: a1a,a1a2,a1b2,a1a3,a1a4,a1a5,a1a6,a1b1a" | ||
typeFilter = ${q(node).find('[instanceof Neos.Neos:Test.DocumentType2]').get()} | ||
combinedFilter = ${q(node).find('[instanceof Neos.Neos:Test.DocumentType2][uriPathSegment*="b1"]').get()} | ||
# @todo Fix and re enable `combinedFilter` case | ||
# Result in Neos 8.3: "combinedFilter: a1b1a" | ||
# Result in Neos 9.0: "combinedFilter: a1a,a1a2,a1b2,a1a3,a1a4,a1a5,a1a6,a1b1a" | ||
# combinedFilter = ${q(node).find('[instanceof Neos.Neos:Test.DocumentType2][uriPathSegment*="b1"]').get()} | ||
@process.render = Neos.Neos:Test.RenderNodesDataStructure | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we resolve this todo here or in a followup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhsdesign in a follow up. I did no changes for those operations so this only documents the deviation from 8.3 to 9.0 that was there. The fixes for the other operations already optimize quite a bit that should go to beta1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
children
and find
will have to wait for beta 2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might also be that filter
could benefit from this #4701
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay i thought so already so lets not block this any further ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks great work. Some operations have different priorities either 0 or 100 - probably just due to copy pasta at some point.
i also want to point out that the order of returned items doesnt seem to always reflect the cr philosophy of the closest first, see PrevUntil
expected a1a3,a1a2
actual a1a2,a1a3
So maybe we should fix this - in another cleanup? - and advise people to just reverse if they need the old behaviour ...
Neos.ContentRepository.NodeAccess/Classes/FlowQueryOperations/PrevUntilOperation.php
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
;)
@mhsdesign pushed a change to
... pretty sure the complaints of the linter are not caused by me ... |
Just seen that the same errors now pop up in the 9.0 branch. ... now i am sure i am not guilty |
Thanks @mficzel now its perfect ;) |
…not like the new syntax (yet)
061fe3a
to
e7de457
Compare
Absolute pathes are handled separately as the fizzle parser cannot handle the syntax
e7de457
to
76d0eb8
Compare
I made behat test now run in strict mode, as previously a non implemented snipped would not cause behat to fail??? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice, thank youuuuuu! :)
Upmerge the flowQuery Tests from 8.3, fix bugs and optimize the implementation to reduce the amount of db-queries as far as possible without introducing breakiness. The tests for
unique
andremove
are added here because those operations did not exist in Neos 8.3.The optimizations had to be very defensive and could not improve the
children
andfind
much since the following fizzle features could not be supported by PropertyValueConstraints:=~
,^=~
,*=~
and$=~
(this may be fixed with Streamline case sensitive behavior of PropertyValueCriteria #4721)foo.bar = "baz"
^=
,*=
and$=
This may be optimized further in a future release or a third party package that allows itself more breakiness.
Notes about changes compared to Neos 8.3:
find
with typeFilter has changed. Since this was never guaranteed this is okIn addition:
Nodes::last
method is addedNodes::until
is removed because of broken semantic. BetterAlternatives arepreviousAll
andnextAll
Nodes::isEmpty
add assertions thatfirst
andlast
will return not nullNodeNameFactory::forRoot
is addedRelates: #4702, #4695
Upgrade instructions
Review instructions
This pr contains the upmerge of #4695 and #4702 (follow up) as this will otherwise cause lots of errors after upmerging.
You can compare this by checking out this pr and compare the content of
Neos.Neos/Tests/Behavior/Features/Fusion/FlowQuery.feature
with the 8.3 branch.I consider the current behavior (with this pr) ok for a beta 1 as find (with nodetypes) already returns the correct nodes but ordered differently.
Checklist
FEATURE|TASK|BUGFIX
!!!
and have upgrade-instructions