#1168 Add support for array parameters on the SQLFilter #5571
Conversation
|
This resolves #2624 |
|
This adds a few new ways in which the SQLFilter can fail horribly. If objects are used as parameters, and the objects are later changed without calling setParameter again, this would break query caching in hard to debug ways. |
|
@zeroedin-bill, and that would not be possible when only one parameter was used instead of an array of parameters? |
| @@ -72,7 +73,11 @@ | |||
| final public function setParameter($name, $value, $type = null) | |||
| { | |||
| if (null === $type) { | |||
| $type = ParameterTypeInferer::inferType($value); | |||
| if (is_array($type)) { | |||
There was a problem hiding this comment.
Block inside this conditional is not reachable.
There was a problem hiding this comment.
Please revert this change to array inferring, the ParameterTypeinferer is already responsible for that itself.
Then this PR is good to go for 2.9.x in my POV.
|
@holtkamp Mostly referring to the Traversable possibility. If you pass an array, and the original array changes after it is passed, you would not affect the filter in any way, because the filter would hold a copy. If you pass a Traversable object, and then change that object after it was passed to the filter, the filter's state could change without setting the dirty flag. I don't think anyone should be passing an object to a SQLfilter period, for that reason. The SQLFilter interface and phpdoc kind of hints that anything passed should be primitive, but it's not specified explicitly. The documentation should be made more explicit about what not to do with a SQLFilter, really, but that's not really in the scope of this PR. This needs more tests IMO, especially around the |
|
Closing in favor of #8375 |
No description provided.