feat: Use CTEs instead of UNIONs to batch queries.

[stephenh]

This PR changes Joist's "auto-batch em.find/SELECT queries" from using UNION ALLs to a CTE of VALUES.

Previously Joist would batch two em.finds into a single SQL query that the two potentially random queries (other than being for the same entity) stitched together with a UNION ALL:

  (select *, -1 as __tag, -1 as __row from "authors" where "id" = $1)
  union all (select "a".*, 0 as __tag, row_number() over () as __row from "authors" as "a" where "a"."id" = $2 order by "a"."id" ASC, "a"."id" asc limit $3)
  union all (select "a".*, 1 as __tag, row_number() over () as __row from "authors" as "a" where "a"."id" = $4 order by "a"."age" DESC, "a"."id" asc limit $5) order by "__tag" asc",

The __tag syntax was used to tell which em.find a returned row belonged two, i.e. if we had three em.finds in this batch, we'd want to know the 2nd union all's rows should go to the 2nd em.finds result set.

This UNION ALL approach seemed fine in theory, but resulted in pretty gnarly queries, and indeed in practice we found it didn't scale once N got to ~50 or so. It makes sense that auto-batch 1,000 queries at once is probably a bad idea, but 50 seems reasonable.

One good aspect of the UNION ALL approach is that it let each query have its own order by, limit, and offset, because each of those would be applied within each UNION ALL.

In the new approach, we don't use UNIONs, and instead leverage the recent parseFindQuery infra to only batch queries by entity (as before) but also by entity + by shape of the query (new to this approach). With this constraint, that all queries in the batch have the same tables + joins + filters, we can more effectively make them "one query", but with the aggregated WHERE clause represented as a JOIN:

"WITH _find (tag, arg0) AS (VALUES ($1::int, $2::int), ($3, $4) )
SELECT array_agg(_find.tag) as _tags, "a".*
FROM authors as a
JOIN _find ON a.id = _find.arg0 GROUP BY "a".id
ORDER BY a.first_name DESC LIMIT 10000;",

The reason for the CTE of VALUES + JOIN, instead of just OR-ing all of the parameters is that, with OR, if a row matches multiple em.finds, it will only be returned once; but b/c we've added tag as a column to the VALUES, and each em.find caller gets its own tag, the same row will be returned multiples times (although we array_agg the tag to avoid actually returning the row twice), once per time it matched one of the em.finds.

Surprisingly enough, operators like <= even work in JOIN clauses, using a feature called "non-equi joins".

But, if callers want to use limits and offsets, they'll have to use the new findPaginated, which will not auto-batch and will N+1 if called in a loop. This should be fine b/c typically findPaginated calls would be at the top-most level of an API endpoint/graphql query.

Fixes #441

[stephenh]

🎉 This PR is included in version 1.77.0 🎉

The release is available on:

• v1.77.0
• GitHub release

Your semantic-release bot 📦🚀