doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-23 22:42:18 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

[PR #12190] [MERGED] Fix collection filtering API for IN/NOT IN comparisons that require type conversions #13560

New Issue
Closed
opened 2026-01-22 16:17:33 +01:00 by admin · 0 comments
admin commented 2026-01-22 16:17:33 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/doctrine/orm/pull/12190
Author: @mpdude
Created: 10/7/2025
Status: ✅ Merged
Merged: 10/16/2025
Merged by: @greg0ire

Base: 2.20.x ← Head: criteria-matching-custom-type-retry

📝 Commits (1)

  • 7a59281 Fix collection filtering API for IN/NOT IN comparisons that require type conversions

📊 Changes

11 files changed (+226 additions, -43 deletions)

View changed files

📝 phpstan-baseline.neon (+0 -6)
📝 src/Persisters/Collection/ManyToManyPersister.php (+7 -7)
📝 src/Persisters/Entity/BasicEntityPersister.php (+63 -27)
📝 src/Persisters/Entity/EntityPersister.php (+1 -1)
📝 tests/Tests/Models/ValueConversionType/InversedManyToManyEntity.php (+6 -0)
📝 tests/Tests/Models/ValueConversionType/InversedOneToManyEntity.php (+1 -1)
📝 tests/Tests/Models/ValueConversionType/OwningManyToManyEntity.php (+6 -0)
📝 tests/Tests/Models/ValueConversionType/OwningManyToOneEntity.php (+6 -0)
➕ tests/Tests/ORM/Functional/ValueConversionType/ManyToManyCriteriaMatchingTest.php (+65 -0)
➕ tests/Tests/ORM/Functional/ValueConversionType/OneToManyCriteriaMatchingTest.php (+65 -0)
📝 tests/Tests/ORM/Persisters/BasicEntityPersisterTypeValueSqlTest.php (+6 -1)

📄 Description

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

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/doctrine/orm/pull/12190 **Author:** [@mpdude](https://github.com/mpdude) **Created:** 10/7/2025 **Status:** ✅ Merged **Merged:** 10/16/2025 **Merged by:** [@greg0ire](https://github.com/greg0ire) **Base:** `2.20.x` ← **Head:** `criteria-matching-custom-type-retry` --- ### 📝 Commits (1) - [`7a59281`](https://github.com/doctrine/orm/commit/7a5928115745a47dde054b12647d425a7ffcb5d7) Fix collection filtering API for IN/NOT IN comparisons that require type conversions ### 📊 Changes **11 files changed** (+226 additions, -43 deletions) <details> <summary>View changed files</summary> 📝 `phpstan-baseline.neon` (+0 -6) 📝 `src/Persisters/Collection/ManyToManyPersister.php` (+7 -7) 📝 `src/Persisters/Entity/BasicEntityPersister.php` (+63 -27) 📝 `src/Persisters/Entity/EntityPersister.php` (+1 -1) 📝 `tests/Tests/Models/ValueConversionType/InversedManyToManyEntity.php` (+6 -0) 📝 `tests/Tests/Models/ValueConversionType/InversedOneToManyEntity.php` (+1 -1) 📝 `tests/Tests/Models/ValueConversionType/OwningManyToManyEntity.php` (+6 -0) 📝 `tests/Tests/Models/ValueConversionType/OwningManyToOneEntity.php` (+6 -0) ➕ `tests/Tests/ORM/Functional/ValueConversionType/ManyToManyCriteriaMatchingTest.php` (+65 -0) ➕ `tests/Tests/ORM/Functional/ValueConversionType/OneToManyCriteriaMatchingTest.php` (+65 -0) 📝 `tests/Tests/ORM/Persisters/BasicEntityPersisterTypeValueSqlTest.php` (+6 -1) </details> ### 📄 Description 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 #11897. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
admin added the pull-request label 2026-01-22 16:17:33 +01:00
admin closed this issue 2026-01-22 16:17:33 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#13560
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?