Open spackmat opened 1 year ago
Hi @spackmat,
Thx for the PR.
I need to found a moment to check your PR, did you add tests? Because you have just change an existant test :thinking:
did you add tests? Because you have just change an existant test 🤔
I did not add tests for that case, because the fixtures don't contain a relation, on which an in()
expression could be tested. So I just changed the few tests that test createCondition()
at all so they use query parameters instead of embedding the value-strings inside the expression. They all use my proposed ExpressionParameterValue
class, which in that case is not really necessary, but at least creates a litte test coverage for that class.
I also removed the internal usages of the old parameter-array-format and changed them to use the ExpressionParameterValue
, so now I could also trigger a deprecation message, when that parameter-array-format is detected. Should I implement that by?
@trigger_error('Setting Expression parameters with array format `[$value, $type]` is deprecated, use `new ExpressionParameterValue($value, $type)` instead.', \E_USER_DEPRECATED);
Fixes the problem described in https://github.com/lexik/LexikFormFilterBundle/issues/364 where array values for parameters of filter expressions are misinterpreted as [value, type] pairs, throwing strange errors within Doctrine.
When the value (with an optional type) is wrapped inside a
ExpressionParameterValue
value object, theDoctrineApplyFilterListener
detects and used that explicit declaration. When the value is an array, it is checked if it contains a valid DBAL-type string on the second element, before it is assumed that it contains an implicit type decleration in that old array form. That branch can be deprecated in favor of the explicit declaration using the newExpressionParameterValue
class.