mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Passing an integer array as parameter to doctrine SQL filter failes #5122
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 @Nepoh on GitHub (May 9, 2016).
I tried to pass an array of integers to
Doctrine\ORM\Query\Filter\SQLFilter::setParameterwith theDoctrine\DBAL\Connection::PARAM_INT_ARRAYparameter type as I did with regular queries many times before to use the parameter in SQL IN() statements.The documentation says
Doctrine\ORM\Query\Filter\SQLFilter::getParametertakes care of parameter quoting:but it looks like the parameter type is not handled correctly and an exception is thrown:
Is this a bug or why are array parameters not allowed?
Some code snippets of what I did: I have a filter class
and a configurator class to pass some parameters
@stedekay commented on GitHub (Nov 16, 2016):
Any news on this issue? Also trying to use an array for an IN-statement.
@dimkasta commented on GitHub (Jul 21, 2017):
Any news?
How this should be handled?
Would FIND_IN_SET be a legit solution?
@24HOURSMEDIA commented on GitHub (Oct 9, 2017):
I have problems with this too, I implemented multiple indexed parameters for the use case but that is definitely not scalable. I don't see why a custom filter is not allowed to accept the raw parameter value..
very bad solution.
Another, perhaps better workaround, would be to create a custom method in your filter, and then take care of escaping etc in the filter yourself:
@lcobucci commented on GitHub (Oct 9, 2017):
That's kind of weird, what version of the ORM are you using? The last stable version uses the
ParameterTypeInfererto use the correct type, which behaves properly with arrays.Could you please send us a failing test case that reproduces that behaviour? It would help us a lot to identify and fix the issue you're describing.
You can find examples on
388afb46d0/tests/Doctrine/Tests/ORM/Functional/Ticket@24HOURSMEDIA commented on GitHub (Oct 9, 2017):
Hi I don't have too much time but I ran this short test code which illustrates the problem.
Best I could get in the filter was a quoted php serialized object..
(strings are used instead of the integer mentioned in the issue but the error messages are the same)
The context is within Symfony 3.3 framework, library versions are:
Test code:
@spackmat commented on GitHub (Apr 11, 2018):
Any news on that? I can confirm this problem with doctrine/orm 2.6.1 and doctrine/dbal 2.7.0 in a Symfony 4 application. The code calls the PDO quote method, where the value of 101 (from Connection::PARAM_INT_ARRAY) is ignored, PDO has no param type for arrays, at least not as a const with that value.
@videni commented on GitHub (Sep 12, 2018):
I also have this problem
@Ocramius commented on GitHub (Sep 12, 2018):
Send a test, then we can patch it, if applicable.
@guillaumebdx commented on GitHub (Feb 27, 2019):
To figure this out, I have made an implode/explode of my array.
Now, I can set an array in filter setParameter like this
Hope this can help somebody
@ghost commented on GitHub (Sep 12, 2019):
For
Expression should result in
@edigu commented on GitHub (Oct 6, 2019):
I hit the same issue today when implementing a custom filter. For my use case it looks like a weird PDO behavior, reported as bug here in 2009.
Doctrine\ORM\Query\Filter\SQLFilter::getParameterretrieves a\Doctrine\DBAL\Connectioninstance fromEntityManagerto quote parameter value through it.Connection::quoteonly proxies the parent's interface ():So in my case, the PDO driver was failing, even doctrine properly passes value and type information to underlying layers.
Since MySQL is also happy when parsing such statement on
status_id (int)column:I stopped annoying from this.