Repository navigation
Fix whereIn/orWhereIn with empty lists, qualify OR columns, add whereNotIn to the query builder - #395
Merged
techmahedy merged 1 commit intoOct 30, 2026
Conversation
…NotIn to the query builder
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Checklist
Description
Fixes a bug in
whereIn()/orWhereIn()with an empty list, plus the related problems in the same methods, in both the model builder and the plain query builder.1. An empty
INlist compared the column to the string'NULL'whereIn($field, [])was turned intowhere($field, '=', 'NULL'), which binds the text'NULL', not SQL NULL. An emptyINmust match nothing, but:NULL.whereIn('label', [])->delete()really deleted such a row, andupdate()modified it.'NULL'to0, so reads matched rows equal to0. In strict mode,delete()andupdate()threwSQLSTATE[22007], so a normal "no ids selected" bulk action crashed.Empty lists are now registered as an
INcondition and compiled by the existing condition compiler, which already produced1=0for an emptyINand1=1for an emptyNOT IN.2. Related problems in the same methods
orWhereIndid not qualify its column the waywhereIndoes, so on a join it failed with "ambiguous column". Both now qualify bare columns. Already-qualified columns are left alone.whereInbroke on an aliased table. It builtitems as i.id, a syntax error. All IN conditions now use the alias (i.id), includingitems iwithoutas.whereNotIn/orWhereNotIn. The call fell through to__calland produced a syntax error. Both are added.['a' => 1, 'b' => 2]) could not be bound. Values are now re-indexed.Changes
addInCondition()andtableReference()toInteractsWithConditionBinding, which both builders already use.tableReference()out ofInteractsWithSoftDeleteScopeinto that trait. Only the two builders use either trait.whereIn,orWhereIn,whereNotInandorWhereNotInon both builders delegate toaddInCondition(). The privateaddNotInCondition()on the model builder is gone.EmptyWhereInTestwith 87 tests that run against both builders.Checklist