In that case, I would say it is correctly set, if you pass null or a value that is null (you should always check if the value is not null), then doing where('name', '=', null) or where('name', null) should still do is null and not null or any other behavior. I do see you want to prevent the framework from assuming is null when you do where('name', '=', null) or the value is null if you do not know the value before hand.
What I do not understand is why would I use where name null instead of is null? I have never saw someone use that (I am not DBA), but just curious, why would Laravel need to change that behaviour? What value would it add? If it's a design choice that won't be changed, that's fine and I'll do raw queries, but one can be curious to why it's as such when it can lead to completely flipping your query on it's head. My thought is more that, if I am explicit on my operator, Laravel should not be assuming what I am actually trying to do, as I clearly stated it. select * from `users` where `name` is nullīut this assumption is doing the exact opposite of the result you're trying to achieve.
With valid SQL we can just make use of the = operator and yield the same result without the multiple NOT NULL cases. However, if you have to apply this logic for multiple fields, it can quickly become a mess. In supported drivers, the spaceship operator ( ) exists and is NULL-safe equal to, while the = operator is not null safe.Īssume you have to do a query for a database lookup to find where name is equal to but not null, the query builder is intuitive enough to chain a whereNotNull and where. However, this can sometimes yield unexpected results.
Laravel check no results from eloquent find drivers#
Database Driver & Version: MySQL 8.0.29 / SQLite 3.38.5 (Relateable to Postgres and other drivers as well.)Ĭurrently the query builder WHERE clause assumes if the $value is null, that the developer wants to do a IS NULL check.
0 kommentar(er)
