[All] Fix $count/extras filter columns being re-aliased to the root table in relational queries

[Develop-KIM]

What this fixes

Fixes #4169
Fixes #4836

When a $count(otherTable, <filter>) (or any nested SQL that references another table's columns) is used as an extras value in a relational query, the generated count subquery rewrites every column — including the other table's columns — to the root query's alias. The subquery then references a column that doesn't exist and the query throws.

Reproduction

db.query.candidates.findMany({
  extras: {
    activeJobs: db.$count(
      jobCandidacy,
      and(
        eq(jobCandidacy.candidateId, candidates.id),
        not(inArray(jobCandidacy.status, ['rejected', 'withdrawn'])),
      ),
    ).as('activeJobs'),
  },
});

Before — job_candidacy columns get the root candidates alias:

(select count(*) from "job_candidacy"
 where ("candidates"."candidate_id" = "candidates"."id"
        and not "candidates"."status" in ($1, $2)))
-- ERROR: column candidates.candidate_id does not exist

After — only root-table columns are re-aliased:

(select count(*) from "job_candidacy"
 where ("job_candidacy"."candidate_id" = "candidates"."id"
        and not "job_candidacy"."status" in ($1, $2)))

Root cause

mapColumnsInSQLToAlias (drizzle-orm/src/alias.ts) walks every chunk of the SQL and applies aliasedTableColumn(c, alias) to any Column, with no check that the column belongs to the table being aliased. The relational query builder calls it for the where, extras and orderBy values of each query, so columns of unrelated tables embedded in those SQLs (via $count, correlated subqueries, etc.) get the wrong qualifier.

The change

• mapColumnsInSQLToAlias / mapColumnsInAliasedSQLToAlias take an optional table argument. When provided, a column is only re-aliased if it belongs to that table. Ownership is compared by the table's original (pre-alias) schema-qualified name, so columns referenced through an alias proxy still match the underlying table. When table is omitted, the previous behaviour (re-alias every column) is preserved, so existing callers are unaffected.
• Columns that can't be attributed to a concrete table (e.g. view / subquery selections) fall back to the old behaviour.
• The relational-query call sites (where, extras, orderBy) now pass the query's table, across all dialects: pg, mysql, sqlite, singlestore and gel.

Tests

Added a regression test to integration-tests/tests/relational/bettersqlite.test.ts that runs a $count(postsTable, eq(postsTable.ownerId, usersTable.id)) inside extras, asserts the generated SQL keeps "posts"."owner_id" (never "users"."owner_id"), and executes it against an in-memory database to confirm the correct per-row counts. The test fails on main (throws no such column) and passes with this change; the rest of the relational sqlite suite continues to pass.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 27d1721fe5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid re-aliasing aliased self-table columns

When the nested SQL uses a second alias of the same physical table (common for self-relations), this original-name comparison treats that foreign alias as belonging to the outer RQB table. For example, a users extras $count over users as invitees with a filter like eq(invitees.invitedBy, users.id) will still rewrite invitees.invited_by to the outer users alias, producing the same invalid or wrongly correlated count this change is trying to avoid. The ownership check needs to distinguish aliases of the same base table rather than matching only the original schema/name.

Useful? React with 👍 / 👎.