Fix collection filtering API for IN/NOT IN comparisons that require type conversions
#12190
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
mpdude
force-pushed
the
criteria-matching-custom-type-retry
branch
from
f6d4c47 to
bd86a47
Compare
morozov
previously approved these changes
Oct 9, 2025
|
The commits would need to be squashed either by you or the person who merges. |
greg0ire
reviewed
Oct 10, 2025
tests/Tests/ORM/Functional/ValueConversionType/ManyToManyCriteriaMatchingTest.php
Outdated
Show resolved
Hide resolved
tests/Tests/ORM/Functional/ValueConversionType/ManyToManyCriteriaMatchingTest.php
Outdated
Show resolved
Hide resolved
…ype conversions This PR fixes the `Criteria` matching API for `IN` and `NIN` conditions with values that are arrays, by making sure that type information for the matched field is passed to the DBAL level correctly. Passing the right parameter type to DBAL is important to make sure parameter conversions are applied before matching at the database level. Memory-based collections (`ArrayCollection`s or initialized collection fields) would perform matching on the objects in memory where no type conversion to the database representation is required, giving correct results. But uninitialized collections that have their conditions evaluated at the database level need to convert parameter values to the database representation before performing the comparison. One extra challenge is that the DBAL type system does currently not support array-valued parameters for custom types. Only a [limited list of types](https://www.doctrine-project.org/projects/doctrine-dbal/en/4.2/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion) is supported. I discussed this with @morozov at the Doctrine Hackathon and came to the conclusion that it would be best to work around this limitation at the ORM level. Thus, this fix recognizes array-valued parameters and creates multiple placeholders (like `?, ?, ?`) for them, flattening out the arrays in the parameter list and repeating the type information for each one of them. Previous stalled attempt to fix this was in doctrine#11897.
greg0ire
force-pushed
the
criteria-matching-custom-type-retry
branch
from
0d93196 to
7a59281
Compare
greg0ire
approved these changes
Oct 13, 2025
SenseException
approved these changes
Oct 14, 2025
|
Thanks @mpdude |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This PR fixes the
Criteriamatching API forINandNINconditions with values that are arrays, by making sure that type information for the matched field is passed to the DBAL level correctly.Passing the right parameter type to DBAL is important to make sure parameter conversions are applied before matching at the database level.
Memory-based collections (
ArrayCollections or initialized collection fields) would perform matching on the objects in memory where no type conversion to the database representation is required, giving correct results.But uninitialized collections that have their conditions evaluated at the database level need to convert parameter values to the database representation before performing the comparison.
One extra challenge is that the DBAL type system does currently not support array-valued parameters for custom types. Only a limited list of types is supported.
I discussed this with @morozov at the Doctrine Hackathon and came to the conclusion that it would be best to work around this limitation at the ORM level. Thus, this fix recognizes array-valued parameters and creates multiple placeholders (like
?, ?, ?) for them, flattening out the arrays in the parameter list and repeating the type information for each one of them.Previous stalled attempt to fix this was in #11897.