After the functionality introduced in this PR https://github.com/dwightwatson/validating/pull/180
the semantic of the additional params of the 'NULL' string changed in a way that is not BC. This leads to produced queries that are not equivalent.
If I have a rule like unique:users,user_id,1,id,deleted,null what happens in prepareUniqueRule is that in $parameters the string null is replaced by a NULL value (returned by the model) and when the rule is generated by imploding $parameters, the NULL value is converted to an empty string, changing (and breaking) the semantic of the query.
The query produced by the broken rules goes from
SELECT COUNT(*) ... WHERE deleted IS NULL
to
SELECT COUNT(*) ... WHERE deleted = ""
I'll submit a PR to fix this issue in the next few hours
After the functionality introduced in this PR https://github.com/dwightwatson/validating/pull/180 the semantic of the additional params of the 'NULL' string changed in a way that is not BC. This leads to produced queries that are not equivalent.
If I have a rule like
unique:users,user_id,1,id,deleted,null
what happens inprepareUniqueRule
is that in$parameters
the stringnull
is replaced by aNULL
value (returned by the model) and when the rule is generated by imploding$parameters
, theNULL
value is converted to an empty string, changing (and breaking) the semantic of the query.The query produced by the broken rules goes from
to
I'll submit a PR to fix this issue in the next few hours