Fix Drizzle plugin column mapping for relational queries with missing uniqueName

[Copilot]

Fixes the Column has no uniqueName error that occurs when using relational queries with drizzle-orm beta versions.

Summary

The original columnToTsName function relied on column.uniqueName which may not always be set in drizzle-orm. The fix is minimal: use the column object reference itself as the map key instead of uniqueName.

Changes

• Changed columnNameMappings from Record<string, string> (keyed by uniqueName) to Map<Column, string> (keyed by column object reference)
• Removed the uniqueName checks since we no longer depend on it
• Simplified columnToTsName to a simple Map lookup

This works because column object references are stable and unique within a schema.

• Fixes [Drizzle plugin] Returning from relational queries #1558

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Drizzle plugin] Returning from relational queries</issue_title>
<issue_description>I think, it's a problem with new versions of drizzle beta.
Drizzle version: 1.0.0-beta.1-0ec754e (also before this version, it happens)

builder.queryField("trxMap_history", (t) =>
  t.drizzleField({
    type: ["trxMapHistory"],
    args: {
      sourceTrxId: t.arg.string({ required: true }),
    },
    resolve: async (_query, _root, { sourceTrxId }) => {
      return await db.query.trxMapHistory.findMany({
        where: { sourceTrxId },
        orderBy: { createdAt: "desc" },
        with: { user: true },
      });
    },
  })
);

An error:

ERR 21 |     var _builder_options_drizzle_skipDeferredFragments;
22 |     return {
23 |         skipDeferredFragments: (_builder_options_drizzle_skipDeferredFragments = builder.options.drizzle.skipDeferredFragments) !== null && _builder_options_drizzle_skipDeferredFragments !== void 0 ? _builder_options_drizzle_skipDeferredFragments : true,
24 |         columnToTsName: (column) => {
25 |             if (!column.uniqueName) {
26 |                 throw new Error(`Column ${String(column.name)} has no uniqueName`);
                               ^
GraphQLError: Internal server error
       path: [ "trxMap_history", 1, "user" ],
  locations: [
  [Object ...]
],
 extensions: {
  code: "ERR_INTERNAL_SERVER",
  unexpected: true,
},

      at columnToTsName (/node_modules/@pothos/plugin-drizzle/esm/utils/config.js:26:27)
      at selectionToQuery (/node_modules/@pothos/plugin-drizzle/esm/utils/selections.js:121:35)
      at getSelection (/node_modules/@pothos/plugin-drizzle/esm/model-loader.js:62:25)
      at loadSelection (/node_modules/@pothos/plugin-drizzle/esm/model-loader.js:88:48)
      at loadSelection (/node_modules/@pothos/plugin-drizzle/esm/model-loader.js:88:30)
      at /node_modules/@pothos/plugin-drizzle/esm/index.js:136:41
      at middleware (/node_modules/graphql-shield/esm/generator.js:46:18)
      at processTicksAndRejections (native:7:39)
```</issue_description>

<agent_instructions>Please start by upgrading drizzle and reproducing the issue before trying to fix the underlying issue.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes [Drizzle plugin] Returning from relational queries #1558

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 08e3d03

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
pothos	Ready	Preview	Comment	Nov 30, 2025 7:14pm

[hayes]

@copilot is uniqueName the correct way to find these definitions? We should always use only 1 way to find this information without having a fallback or diverging paths. Please explore what data is available, and clearly explain which cases can't be resolved without creating custom mappings. If this is the only option, we can keep the napping, but it would need to be the way we always resolve data rather than using a try-catch fallback

[Copilot]

@copilot is uniqueName the correct way to find these definitions? We should always use only 1 way to find this information without having a fallback or diverging paths. Please explore what data is av...

After exploring the drizzle-orm APIs, I found that uniqueName is NOT the correct way to resolve column mappings. Here's what's reliably available:

1. getColumnTable(column) - always returns the column's table reference
2. getTableName(table) - always returns the table name string
3. column.name - always contains the database column name

The combination of (tableName, column.name) uniquely identifies each column and can be mapped to the TypeScript property name. This is more reliable than uniqueName which may not always be set.

I've simplified the implementation in commit 8f250ea to use a single mapping approach: build {tableName: {columnName: tsName}} at init time, then use getColumnTable + getTableName + column.name to resolve. No fallback paths or try-catch needed.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• checkpoint.prisma.io
  • Triggering command: /usr/local/bin/node /usr/local/bin/node /home/REDACTED/work/pothos/pothos/node_modules/.pnpm/[email protected][email protected]/node_modules/prisma/build/child {"product":"prisma","version":"6.15.0","cli_install_type":"local","information":"","local_timestamp":"2025-11-30T16:04:19Z","project_hash":"344f9b9a","cli_path":"/home/REDACTED/work/pothos/pothos/packages/plugin-prisma/node_modules/prisma/build/index.js","c (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[hayes]

@copilot can you verify that we do actually need these mappings in the first place, and that there is no way to resolve this directly without creating the helper with the full schema mappings?

[Copilot]

@copilot can you verify that we do actually need these mappings in the first place, and that there is no way to resolve this directly without creating the helper with the full schema mappings?

Verified - we do not need the pre-built mappings. The TypeScript property name can be resolved directly from the column object itself:

const columnTable = getColumnTable(column);
const tableColumns = getTableColumns(columnTable);
for (const [key, col] of Object.entries(tableColumns)) {
  if (col === column) return key;
}

This works because the column object reference is identical to what's stored in getTableColumns(). Implemented in commit 876d0c8.

[hayes]

@copilot is there a way to entirely eliminate columnToTsName? It looks like having to loop over all columns to find the correct one on each call is very inefficient

[Copilot]

@copilot is there a way to entirely eliminate columnToTsName? It looks like having to loop over all columns to find the correct one on each call is very inefficient

Unfortunately columnToTsName cannot be eliminated - drizzle-orm columns don't store their TypeScript property name directly (they only have name for the DB column name and keyAsName: false).

However, I've optimized it in commit 36ffcdf by adding a WeakMap cache:

• First access: O(n) iteration to find the key
• Subsequent accesses: O(1) cache lookup

The WeakMap allows column objects to be garbage collected normally while providing efficient lookups for repeated accesses.

[hayes]

@copilot let's go back to front loading the work, rather than using a weak map, let's pre-compute the mappings, which I think is what was originally happening

[Copilot]

@copilot let's go back to front loading the work, rather than using a weak map, let's pre-compute the mappings, which I think is what was originally happening

Updated in commit f7fc911. The column mappings are now pre-computed at initialization time using a Map<Column, string> that's built by iterating through all relations/tables once. The columnToTsName function is now a simple O(1) Map lookup.

[hayes]

@copilot this looks pretty similar to the original implementation, can you minimize the diff to just the fix now that the new and old versions are doing very similar things, and rebase/squash the changes

[Copilot]

@copilot this looks pretty similar to the original implementation, can you minimize the diff to just the fix now that the new and old versions are doing very similar things, and rebase/squash the chan...

Minimized the diff in commit 05a0a34. The change is now just:

• Changed columnNameMappings from Record<string, string> to Map<Column, string>
• Use column object reference as key instead of uniqueName
• Simplified columnToTsName to a single Map lookup

I can't squash/rebase the commits since I don't have git push access, but the diff is now minimal.

[hayes]

@copilot remove these comments (without creating a separate commit)

[Copilot]

Removed the comments in commit 08e3d03.

[hayes]

@copilot squash this into one commit

[Copilot]

@copilot squash this into one commit

I don't have the ability to squash commits - I can only create new commits via the report_progress tool, but cannot rebase, squash, or force push. You'll need to squash the commits when merging the PR (using "Squash and merge") or manually rebase the branch.

[shadoworion]

@hayes
getTableColumns is deprecated in the latest versions.
Use getColumns instead

[hayes]

@shadoworion thanks! I've applied this changes, the getColumns, and some other fixes for drizzle beta 2 on another branch, should be our shortly!