where('column', false) behaves differently than whereNot('column'), even for a boolean column

[danon]

I have a table like that:

Schema::table('users', function (Blueprint $table) {
    $table->boolean('is_flag')->default(false);
});

And these two calls yield different results:

/**
 * @param Eloquent\Builder $model
 */
public function apply($model): Eloquent\Builder {
    return $model->whereHas('user', 
        fn(Eloquent\Builder $sub) => $sub->where('is_flag', false));
}

/**
 * @param Eloquent\Builder $model
 */
public function apply($model): Eloquent\Builder {
    return $model->whereHas('user', 
        fn(Eloquent\Builder $sub) => $sub->whereNot('is_flag'));
}

[macropay-solutions]

    public function whereNot($column, $operator = null, $value = null, $boolean = 'and')
    {
        return $this->where($column, $operator, $value, $boolean . ' not');
    }

Your examples are not equivalent in logic.

[danon]

Your examples are not equivalent in logic.

I know, but that's the point.

$q->where('is_flag', false) and $q->whereNot('is_flag') look like they are identities.

PS: Like $flag == $false is the same as !$flag.

[macropay-solutions]

https://laravel.com/docs/12.x/queries#where-not-clauses
whereNot is to be used in a different manner.

[danon]

The method signatures of where() and whereNot() are identical; hence to an regular user it looks like they should be opposites of one another.

[macropay-solutions]

It just looks but it does not work like that. Just ignore this whereNot function as it is just an overhead that got into the framework because someone needed it and so all of use "should need it".

[danon]

It just looks but it does not work like that. Just ignore this whereNot function as it is just an overhead that got into the framework because someone needed it and so all of use "should need it".

I mean that's the whole point - it looks like it, but doesn't. It's bad design.