Skip to content
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

Merged
merged 17 commits into from
Feb 2, 2024

Conversation

mficzel
Copy link
Member

@mficzel mficzel commented Nov 3, 2023

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 and remove 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 and find much since the following fizzle features could not be supported by PropertyValueConstraints:

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:

  • The order of nodes returned by find with typeFilter has changed. Since this was never guaranteed this is ok

In addition:

  • Nodes::last method is added
  • Nodes::until is removed because of broken semantic. BetterAlternatives are previousAll and nextAll
  • Nodes::isEmpty add assertions that first and last will return not null
  • NodeNameFactory::forRoot is added

Relates: #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

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

…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
@mficzel mficzel force-pushed the 90/verifyAndOptimizeFlowQuery branch from 4940424 to 37d901e Compare November 3, 2023 16:36
@mficzel mficzel marked this pull request as ready for review November 3, 2023 16:48
@mhsdesign
Copy link
Member

Fyi to why until will be removed https://neos-project.slack.com/archives/C3MCBK6S2/p1699020664345879

@mhsdesign mhsdesign changed the title TASK: Verify and optimize flowQery operations TASK: Verify and optimize FlowQuery operations Nov 4, 2023
@mhsdesign
Copy link
Member

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.

mficzel and others added 3 commits November 4, 2023 17:59
…ifyAndOptimizeFlowQuery

# Conflicts:
#	Neos.Neos/Tests/Behavior/Features/Fusion/FlowQuery.feature
Co-authored-by: Marc Henry Schultz <85400359+mhsdesign@users.noreply.github.com>
@mficzel
Copy link
Member Author

mficzel commented Nov 4, 2023

@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.

@mficzel
Copy link
Member Author

mficzel commented Nov 4, 2023

I suggest to look into the children and find operation again in a follow pr as those are more complex and still look weird inside.

Comment on lines 352 to 361
# @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
}
Copy link
Member

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?

Copy link
Member Author

@mficzel mficzel Nov 6, 2023

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

Copy link
Member Author

@mficzel mficzel Nov 6, 2023

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

Copy link
Member Author

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

Copy link
Member

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 ;)

Copy link
Member

@mhsdesign mhsdesign left a 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 ...

Copy link
Member

@mhsdesign mhsdesign left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

;)

@mficzel
Copy link
Member Author

mficzel commented Nov 7, 2023

@mhsdesign pushed a change to

  • restore the operation priority as it was in 8.3 (100 for operatins that override derfault flowQuery operations and 0 otherwise)
  • define shortNames for all flowQuery operations

... pretty sure the complaints of the linter are not caused by me ...

@mficzel
Copy link
Member Author

mficzel commented Nov 7, 2023

Just seen that the same errors now pop up in the 9.0 branch. ... now i am sure i am not guilty

@ahaeslich ahaeslich removed the 9.0beta1 label Nov 7, 2023
@mhsdesign
Copy link
Member

Thanks @mficzel now its perfect ;)

@mficzel mficzel force-pushed the 90/verifyAndOptimizeFlowQuery branch from 061fe3a to e7de457 Compare November 10, 2023 17:10
Absolute pathes are handled separately as the fizzle parser cannot handle the syntax
@mficzel mficzel force-pushed the 90/verifyAndOptimizeFlowQuery branch from e7de457 to 76d0eb8 Compare November 11, 2023 10:18
@mhsdesign
Copy link
Member

I made behat test now run in strict mode, as previously a non implemented snipped would not cause behat to fail???
Cant do it on the 9.0 branch as the current 8.3 upmerged flowquery test would fail in that case 😂

@bwaidelich bwaidelich removed their request for review January 17, 2024 14:52
Copy link
Member

@kitsunet kitsunet left a 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! :)

@kitsunet kitsunet merged commit f4f9df6 into neos:9.0 Feb 2, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants