[10.x] Fix CanBeOneOfMany giving erroneous results

[Guilhem-DELAITRE]

This PR topic and content is identical to #46309 except I added a fix for strict RDBMS (like PostgreSQL) which doesn't support approximate usage of aggregate / group by.

[Guilhem-DELAITRE]

Is there anything wrong with my PR preventing it to be merged ?

[driesvints]

@Guilhem-DELAITRE just think Taylor hasn't gotten to this one yet with all the pre and post Laracon US stuff.

[Guilhem-DELAITRE]

@driesvints
Ok, not trying being pushy, I just wanted to know if the PR was lacking anything, thx for the feedback

[taylorotwell]

Why min here? Can you explain the entire logic behind this PR and how it fixes the issue?

[Guilhem-DELAITRE]

The min purpose is to use an aggregate to select any value on a column which we already know all value are the same because it's the sub-level aggregate. We still need an aggregate because there's no group by clause on that column. The most correct solution would probably be to add a group by on that column, but I didn't manage to do it in the time I had.

The more global purpose of the PR is fully stated and detailed (and is demonstrated by the modification of the generated query) in the original PR : #46309

The last two commits purpose is to fix the problem mentionned in
#46394 which was due to my modification not working with DBRMS which are strict with aggregates / group by like PostgreSQL.

[crynobone]

This PR shouldn't be called "Fix" as it introduced new usage from

Current

return $this->hasOne(Profle::class)->ofMany('created_at', 'max');

After

return $this->hasOne(Profle::class)->ofMany([
    'created_at', 'max',
    'updated_at', 'max',
]);

---

Also I believe a similar tests should be added using Integrations tests to confirm the code works on SQLite, MySQL, Postgres and MSSQL.

[Guilhem-DELAITRE]

@crynobone
It doesn't introduce new usage, this usage already exists as can be seen in function price of file tests/Database/DatabaseEloquentHasOneOfManyTest.php

BUT this usage (using multiple aggregate in ofMany method) actually produces erroneous results in cases and for reasons detailed in the following PR : #46309

You are right about the part Also I believe a similar tests should be added using Integrations tests to confirm the code works on SQLite, MySQL, Postgres and MSSQL., and the fact that the pre-existing multi-aggregate ofMany wasn't integration tested with multi databases is the reason the origin PR that I previously mentionned produced errors on PostgreSQL when it was merged.

[crynobone]

Regardless, this need Integration tests

[Guilhem-DELAITRE]

@crynobone
I basically duplicated the test I added in tests/Database into tests/Integration/Database with some tweaks.

Seems that they passed successfully.