PHPORM-60 Fix Query on whereDate, whereDay, whereMonth, whereYear

[GromNaN]

Fix PHPORM-60

Created from mongodb/laravel-mongodb#2376

So basically, current whereDate, whereDay, whereMonth and whereYear is query on different column with specific need (like whereDate you need column that has value YYYY-MM-DD etc) using basic comparison.

As we all know that isnt how whereDate works on sql, this PR will generate query using built in $dayOfMonth, $month, $year on whereDay, whereMonth, and whereYear, while whereDate basically generate range date(since mongodb doesnt have date() equivalent like on sql).

• whereDate uses $lt & $gt comparison with UTCDateTime objects
• whereDay uses $dayOfWeek
• whereMonth uses $month
• whereYear uses $year
• whereTime uses $dateToString to format into H:M:S

[GromNaN]

Added a document without birthday field to test the behavior.

[GromNaN]

I tested this alternative, but got segfaults.

'ne' => ['$not' => [
    $column => [
        '$gte' => $startOfDay,
        '$lte' => $endOfDay,
    ],
]],

[jmikola]

got segfaults

Segfaults in mongod (executing the query) or PHP (executing this match construct)?

I'm trying to think about how this would trigger a segfault in PHP. The only thing I can think of is that $column is referenced at multiple levels of the same return value. If so, that seems like something you might be able to isolate in a PHPT test. I'd be happy to dive into it further if so.

If this is actually a mongod segfault, I assume it'd be reproducible in the shell and would warrant a new SERVER ticket.

[jmikola]

This could result in a subtle behavioral change when using MongoDB\BSON\Regex objects. Quoting $eq docs:

Specifying the $eq
operator is equivalent to using the form { field: } except when the is a regular expression. See below for examples.

[GromNaN]

{ field: { eq: Regex } } is not supported ATM as it will always end to { field: Regex } for matching the regex. I don't think storing Regex in database is common enough to fix it know. PHPORM-74

[jmikola]

Is ltrim() necessary to avoid interpreting a leading zero as octal notation? I would only expect that to apply to integer literals.

In my local testing with a PHP 8.2 REPL, the integer cast seems to ignore leading zeroes.

[GromNaN]

Exactly, I blindly adopted the PR code without even testing it. Fixed.

[jmikola]

I assume $column is created by extract($where). Is there any enforcement on that? It seems hard to track given we have no typing/shape information for the $where array.

Is it possible for $column to be a field path (e.g. foo.bar), or would it only be a top-level field name?

[GromNaN]

Removing all this extract and replacing with array access would be more verbose but a lot more explicit.

[jmikola]

I noted the original author's comment in mongodb/laravel-mongodb#2376:

whereTime isnt possible to fix rn since i cant find logic to query like time() on sql

Does this address that concern?

[GromNaN]

Yes, fixed. There is no dedicated operator, but this was possible using $dateToString.

[GromNaN]

Moved to mongodb/laravel-mongodb#2572