TASK: Fix and improve `find` and `children` flowQuery operation

[mficzel]

The flowQuery operations find and children are fixed & optimized for the new cr. They now use a combined query with nodetype and property criteria when possible. The number of performed db-queries is the number of contextNodes times the number of filterGroups (comma separated parts)

In addition the find operation now can also handle single property criteria and does not rely on having an instanceof filter first.

The solution adds a NodeFilterCriteria class that encapsulates nodeTypeCriteria and PropertyConstraints. The collection object NodeFilterCriteriaGroup combines multiple of those. The NodeFilterCriteriaGroupFactory allows to take a fizzle-expression and create a NodeFilterCriteriaGroup once only Attribute filters (instanceof and property) are used.

Upgrade instructions

Review instructions

This based on #4699 and should be merged afterwards. Also we should discuss how to proceed regarding the case insensitive operators feature https://github.com/neos/flow-development-collection/pull/2600 currently those are handled by the legacy code as fallback.

Checklist

• [x] Code follows the PSR-2 coding style
• [x] Tests have been created, run and adjusted as needed
• [x] 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

[mficzel]

@mhsdesign @nezaniel it is vary well possible that i cracked the find and children flowQuery nut :-) ... needs discussion how to name this and which tests and edge cases i missed

!! The linting errors are coming from upstream !!

[mficzel]

We put this aside as the node filter criteria did not provide the same case-related behavior as the old flowQuery implementation … maybe this has changed in the meantime

Other than that we considered this a bit too dangerous and thought about moving this to a third party package

[mhsdesign]

Yes once https://github.com/neos/neos-development-collection/pull/4725 introduces case insensitive operators we might be able to use satisfy the old flow query api?

i understand that the new cr subgraph api has different features than the feature set of neos 8.3's find or children, but i think the overlap is big enough to use the faster db implementation than to mimic the legacy behaviour by filtering expensively on php.

For legacy use cases we could possibly ship a legacy implementation of find or children in an eel helper LegacyFlowQuery so that people with odd requirements have a change to adjust?

[mficzel]

With the case sensitive operations in place this might be feasible now ...

[mhsdesign]

I almost thought this was merged already. Ill will play around with this a bit but then i think (as all the blockers and adjustments were solved) this is ready to be merged? Would be great to find a second reviewer as well :)

[mhsdesign]

the current find implementation might really be too slow https://neos-project.slack.com/archives/C050C8FEK/p1732015976360459

[mhsdesign]

As outlined here https://github.com/neos/neos-development-collection/issues/4205#issuecomment-2585730632 the performance of the subgraph itself are not desirable and the effort here to apply more specific filters to avoid returning too many nodes and filtering them in php later has only little impact currently.

Also this pr introduces some new complexity for optimising the flow queries with the risk of loosing accidentally features. Now in https://github.com/neos/neos-development-collection/issues/5434 we already described that the current find and children operations are lost world. There might be a dedicated replacement soon that would also query the cr slightly more performantly by only using filters on db side - essentially what this pr does for the legacy operations.

Under that aspect i think we can close this. Thanks for the work still!!!