mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Exception caused by paginating queries with WHERE IN on a custom type field #6308
Reference in New Issue
Block a user
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?
Originally created by @jaikdean on GitHub (Sep 24, 2019).
Originally assigned to: @jaikdean on GitHub.
BC Break Report
Summary
In 2.6.4 an exception is thrown using the paginator on queries with a
WHERE INclause on a field with a custom type. This worked correctly in 2.6.3.Previous behavior
The query ran as expected.
Current behavior
An exception is thrown as a value already in database format is passed to the custom type class to be converted again.
How to reproduce
I'm struggling a little for a concise reproducer, but we use the
ramsey/uuid-doctrinepackage and theUuidBinaryTypefrom it. This stores aRamsey\Uuid\Uuidobject into a binary field in the database.Example query builder usage in a repository class
In this example,
p.useris a many-to-one relationship to theUserentity, which has a binary UUID field as its primary key. Because Doctrine (AFAIK) can only handle array parameters of either strings or ints, we need to manually pass an array of binary strings into the parameter.This query works correctly when run as-is, but when it's passed to the paginator, the exception below occurs…
Example stack trace
@lcobucci commented on GitHub (Sep 24, 2019):
This is an interesting one since we only convert the type of the parameter
:dpidand it shouldn't influence the original query.Would you send as a PR (targeting
2.6) with a failing test that reproduces this? You can useb52ef5a100/tests/Doctrine/Tests/ORM/Functional/Ticket/GH7820Test.phpas example for a custom type similar to theUuidBinaryType.@lcobucci commented on GitHub (Oct 1, 2019):
@jaikdean I've tried to reproduce this in a failing test and failed. I ask you again to send us a failing test otherwise it will be pretty hard to get it fixed (perhaps the sample test case below might help you).
Sample test case
@Wirone commented on GitHub (Oct 11, 2019):
We encountered this problem too in 2.6.4, were struggling with this for few days. Thanks to @jaikdean's comment we tried 2.6.3 and it works. I'll ask my teammate, who've been working on it, to provide some details about issue.
@patrykmartynowicz commented on GitHub (Oct 11, 2019):
As @Wirone mentioned I'll try to provide all I know to help to reproduce error. First of all we've noticed problem is somehow connected with relations between entities. We were using combination of
Doctrine,ApiPlatformandRamsey\Uuid. There were two similar scenarios where only difference was how entites are related. Below you can see mappingProduct entity
Status entity
Variant entity
Variant.Color entity
With these mappings and defining
ApiPlatoformresources when you fetch paginated data using api (GET /api/productsandGET /api/variants) ofProductandVariantentities you receive completly different result.Fetching
Variantcause no errors at all and works just fine, however fetchingProductcrashes due to inconsistency of id.Paginator fetches
$idsatapi/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Pagination/Paginator.php:154doctrine/orm:v2.4.6$idscontains binary string of uuids and this type of data is not acceptable by\Ramsey\Uuid\Doctrine\UuidBinaryOrderedTimeType::convertToDatabaseValueramsey/uuid-doctrine:1.5.0 which causes at the end throwing\Doctrine\DBAL\Types\ConversionException.In this particular case as we can see there are two ways to solve the problem
convertToDatabaseValueto accept binary data and do not try to convert it again. (in my opinion not the best way)Paginatorshould denormalize binary data to acceptably byconvertToDatabaseValueAlso during fetching
Variantentities debuger never stopped at breakpoint in\Doctrine\ORM\Tools\Pagination\Paginator::getIterator. The two things which are different in maping are discriminator mapping way how relations are created. That's why I think focusing on entities relations is the key to problem.I'm not sure if pattern above can be applied to all kinds of custom types but I hope it will helps solving the issue.
specific packages version we use
api-platform/api-pack:v1.2.0api-platform/core:v2.4.7doctrine/orm:v2.6.4ramsey/uuid-doctrine:1.5.0@mleczakm commented on GitHub (Jan 29, 2020):
Looks like problem no longer exists on
2.7.0👏@SenseException commented on GitHub (Jan 29, 2020):
@jaikdean Can you confirm that the current 2.7 doesn't show the mentioned BC break anymore?
@jaikdean commented on GitHub (Jun 25, 2020):
I forgot all about this. Yes, it's fixed in 2.7.