[5.6] Add builder/grammar support for row values in where condition

[mfn]

Support for "row values" is mostly useful when implementing pagination with keysets aka seek method.

Well known pagination with offset/limit has almost linearly bad performance characteristics with every "page" turned. They can't make use of an index to efficiently jump to the result page and thus have to always read from the beginning.

An alternative way is to define predicates to jump to the desired page which can make use of indices. Characteristics of such paginations are:

• no indicator how many pages; best used with "endless scrolling/loading" approaches
• usually stable pages (depending on predicates). Insertion of data on previous pages will not alter the result of the current page

This PR implements the low-level building block. Example:

• instead of ->where(…)->orderBy(…)->offset(100)->limit(10)
• you could use ->where(…)->whereRowValues(['last_update', 'ticket_numbner'], '<', ['2017-12-15 23:00:00', 123])->orderBy(…)->limit(10)
  (iff the business logic of your application allows it)

The benefits/performance characteristics as well as in-depth examples how and why this works are well described at:

• http://use-the-index-luke.com/sql/partial-results/fetch-next-page
• http://use-the-index-luke.com/blog/2013-07/pagination-done-the-postgresql-way
• https://blog.jooq.org/2013/11/18/faster-sql-pagination-with-keysets-continued/

Note

• It currently is already possible to achieve this with ->whereRaw() but after reading http://use-the-index-luke.com/no-offset I figured a direct support for this could be welcome

$builder->whereRaw('(last_update, ticket_number) < (?, ?)', […, …]);

• The naming RowValues may not be obvious to related to this "keyset pagination" or "seek method". But OTOH this seems to be the term describing this particular syntax (I'm not an expert on this topic), that's why I choose it instead of ->whereSeek or ->whereKeysetPagination…
  This may be left open for the future to directly support this via something like ->paginateKeyset() (just thinking out loud)
• Not every database out there supports this syntax. PostgresSQL supports it since a long time; MySQL does but with caveats, etc. There's some information at http://use-the-index-luke.com/sql/partial-results/fetch-next-page about it (not sure if it is accurate/up2date).
• There are ways to emulate this behaviour for databases not supporting this syntax (again, see http://use-the-index-luke.com/sql/partial-results/fetch-next-page), but this is out of the scope of this PR:

SELECT *
  FROM ( SELECT *
           FROM tickets
          WHERE last_update <= ?
            AND NOT (last_update = ? AND number >= ?)
          ORDER BY last_update DESC, number DESC
       )
 WHERE rownum <= 10

[sisve]

So this implements a partially supported syntax for something that is already fully supported in the "full" syntax?

[mfn]

Thanks for the feedback!

Guess it the depends on POV and expectations. Basically, using DB::raw() you can write almost any SQL statement without the need for any of the existing where…-shortcuts 🤷‍♀️ ?

OTOH (although I'm not trying to convince/evangelize anyone here), when I implemented this recently I wished I had a ready-made approach for, because why not; makes code more readable etc.
I think it may help raise awareness also a bit for developers who may not know there are alternative ways to offset/limit which have better performance characteristics (iff the business logic supports it).

But maybe you're right because not every database out there might support that syntax? Not sure how this is properly dealt with in the Builder though. Feedback for that welcome!

[mfn]

I could also imagining this as a building block for a future paginator extension which makes use of this technique instead of offset/limit

[mpyw]

According to SQL Feature Comparison, SQLServer does not support Tuple Comparison syntax. So

(a, b, c) > (1, 2, 3)

should be rewritten to

a=1 and b=2 and c>3
or
a=1 and b>2
or
a>1

If you use SQLServer, still lampager/lampager-laravel: Rapid pagination for Laravel may help implementing cursor pagination.

[driesvints]

@mpyw probably best to attempt PR's. Merged PR's are never revisited here.

[mpyw]

@driesvints Yes I know, I actually agree with the PR method. Just writing reference information for minor users.