When using named arguments in a where(), failing to supply an operator causes null results

[ok200paul]

Laravel Version

11.35.0

PHP Version

8.4.1

Database Driver & Version

Sqlite 3.43.2 2023-10-10 13:08:14 1b37c146ee9ebb7acd0160c0ab1fd11017a419fa8a3187386ed8cb32b709aapl (64-bit)

Description

When using named arguments in a where(), failing to supply an operator causes null results. Running a where() with no named arguments works as expected, and running a where() with all (of the first 3) arguments works. Leaving the operator argument out, when using named arguments, causes the value to be null.

Simple examples:

// Works
$userPosts = UserPost::where(
    'user_id',
    $user->id,
        )->get();
        
// Returns null
$userPosts = UserPost::where(
    column: 'user_id',
    value: $user->id,
        )->get();

// Works
$userPosts = UserPost::where(
    column: 'user_id',
    operator: '=',
    value: $user->id,
        )->get();

I thought it might be something to do with the way func_get_args() works under the hood, - I've put together a couple of tests in the repo nominated in the steps to reproduce that func_get_args faithfully returns the operator even when not supplied with the function call. But then I saw func_num_args() does the same, and there's a bit in the framework in Illuminate/Database/Query/Builder.php that might be getting tripped up by this behaviour

In the test class QueriesUsingPositionalArgumentsNullWithoutOperatorTest I've put in tests for the following

• itReturnsDataWhenOperatorExists
• itReturnsDataWhenOperatorDoesNotExist (fails)
• itReturnsDataWhenOperatorDoesNotExistInteger(fails) - just in case it was something to do with ULIDs beginning with 0
• A couple of tests for func_get_args() returning the operator even when not supplied

I'm unable to find previous issues that mention this behaviour - feel free to call me a dumdum and close if this has been covered / fixed / is generally not advised - thanks all. Might be a doco thing too?

I think it might have something to do with this line and the fact that func_num_args() acts differently based on named arguments:

In our case,

• func_num_args() == 2 when NOT using named arguments and only passing in 2 args
• func_num_args() == 3 when we ARE using named arguments and only passing in 2 args. It adds the $operator arg whether we like it or not.

From https://www.php.net/manual/en/function.func-num-args.php
As of PHP 8.0.0, the func*() family of functions is intended to be mostly transparent with regard to named arguments, by treating the arguments as if they were all passed positionally, and missing arguments are replaced with their defaults. This function ignores the collection of unknown named variadic arguments. Unknown named arguments which are collected can only be accessed through the variadic parameter._

In the evaluation of $useDefault, when using only two named arguments to try to shortcut the operator - func_num_args() comes out at 3, causing the value to come through as null, and causing the query to be incorrect.

Hope this makes sense - cheers all and thanks so much for such an awesome framework 🔥 - PG

Steps To Reproduce

• Clone https://github.com/ok200paul/laravel-positional-argument-query-issue
• Run touch database/database.sqlite
• Run composer install && php artisan migrate:fresh --seed
• Run ./vendor/bin/phpunit --filter=QueriesUsingPositionalArgumentsNullWithoutOperatorTest

2 tests will fail, both expecting to be able to omit the operator named argument in a where() query

[ok200paul]

Not sure this is an idea @crynobone; anyone updating their codebases to use named parameters while omitting the operator of a where() will have reasonably severe data integrity issues with no perceptible complaints from the framework. Your call though!

[crynobone]

Issues are meant for confirmed bugs:

1. The documentation never suggested using named arguments for dynamic parameters usage such as where etc
2. The usage was built way before PHP introduced named arguments, so it was never intended to be expected to work with dynamic parameters.

When $operator can be swapped and become $value it defeats the purpose of using named arguments. Therefore this become an Idea

[ok200paul]

Makes sense. Thanks for clarifying! 👍