[8.x] Cursor pagination fixes

[driesvints]

This PR fixes two three things:

• Proper column distribution for cursor base pagination when working with pivots (probably just an oversight from [8.x] Add cursor pagination (aka keyset pagination) #37216
• Allow usage of aliased columns with order by statements when using cursor based pivots
• Proper attribute retrieval for cursors when combining them with pivot models

Before the second fix, the query builder would generate the following invalid query:

SELECT
    *,
    `friends`.`created_at` AS `friended_at`,
    `users`.*,
    `friends`.`user_id` AS `pivot_user_id`,
    `friends`.`friend_id` AS `pivot_friend_id`,
    `friends`.`created_at` AS `pivot_created_at`,
    `friends`.`updated_at` AS `pivot_updated_at`
FROM
    `users`
    INNER JOIN `friends` ON `users`.`id` = `friends`.`friend_id`
WHERE
    `friends`.`user_id` = ?
    AND `friended_at` < ?
ORDER BY
    `friended_at` DESC
LIMIT 6;

Now it will generate:

SELECT
    *,
    `friends`.`created_at` AS `friended_at`,
    `users`.*,
    `friends`.`user_id` AS `pivot_user_id`,
    `friends`.`friend_id` AS `pivot_friend_id`,
    `friends`.`created_at` AS `pivot_created_at`,
    `friends`.`updated_at` AS `pivot_updated_at`
FROM
    `users`
    INNER JOIN `friends` ON `users`.`id` = `friends`.`friend_id`
WHERE
    `friends`.`user_id` = ?
    AND `friends`.`created_at` < ?
ORDER BY
    `friended_at` DESC
LIMIT 6;

The reason for this is that sql engines need an actual column to sort and can't rely on an aliased column of a result set. By de-aliasing the given columns we circumvent this issue.

I don't think this contains anything breaking but I'm unsure about the usage to detect the column aliasing:

stripos($column, ' as ') !== false

I saw this was used in the base query grammar class as well with the wrap method so I think this will be fine.

This PR will conflict with #37762

Fixes #37400

[driesvints]

@paras-malhotra would appreciate a review if you're willing.

[kamui545]

@driesvints Thank you for your hard work, really appreciate it.

Hydration seems to be working properly for the pivot now!

Sadly, I am still having weird behaviour when browsing the "next" page.

On my playground repo, if you're browsing the next page on the cursorPaginate() without alias, you will have the Only arrays and objects are supported when cursor paginating items error.

Using an alias seems to fix the issue on the playground, however, I tried in my own app and I get the same error even with the alias... I've got no idea what's going on, the code of the playground is based from my app and should be similar... I will keep you updated once I figured out... but for now im banging my head against the wall

[driesvints]

I'll need to check in on that on Thursday. I also see it failing but also can't figure it out atm.

[kamui545]

Ok so after spending some time debugging, the alias is now working properly on my real app as well. I was sorting on a non-unique column, my records all had the same timestamps and the next page returned no results, failing to build the previous cursor because $this->items->first() was null...

Stupid mistake, just like I did on the playground app: it should be sorting on id instead of created_at to make sure it's unique...

The app is still acting weird when not using an alias though. Eg:

$friends = $this->user()
  ->friends()
  ->latest('friends.id')
  ->cursorPaginate();

I am not sure if there is an easy way to fix this.

Maybe creating an alias automatically when a dot is used would do the trick. Just need to make sure it does not collide.

I will investigate further this week.

[paras-malhotra]

@driesvints I went through the code. I think this PR looks good to go. Definitely seems to have been an oversight on my part to not hydrate the pivot relations and not fetch the original columns for the where clause.

I guess #37762 changed the where clauses entirely but this logic would still need to be applied to that PR.

[driesvints]

@kamui545 think I got a fix in for the issue you were experiencing. The app you shared is now fully working with this PR. Can you try to verify that?

@paras-malhotra we pushed one more commit to fix the above. It basically will retrieve attributes on a pivot relationship when the table matches with the first part of the dot notation of a parameter name. I'll try some more use case with other relationship queries tomorrow. But this will essentially allow to filter on non-unique column names as long as the table is prefixed.

[kamui545]

@driesvints Thank you again! It seems to fix ordering on ambiguous columns.

However, I noticed another issue: #37999