Mixed ID types in compatible with numeric user ids #2996

Open
opened 2026-03-13 10:33:27 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @OscarCornish on GitHub (Mar 5, 2026).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

  1. Have a user table with numeric ids
  2. Create rest of tables with UUIDs

generateId:

generateId({ model }) {
  if (model === "user") {
    return false;
  }
  return uuidv7();
},

This works for creating tables, but when searching them it will throw at the adapter because "userId column expected type Int" (or similar)

Current vs. Expected behavior

I want to be able to declare for a table:

  • Let the db generate your id values
  • Those id values will be numeric

But if generateIds is false, then the check for numericIds (generateId === "serial") will not be true

What version of Better Auth are you using?

1.5.1

System info

-

Which area(s) are affected? (Select all that apply)

Backend

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
  advanced: {
    database: {
      generateId({ model }) {
        if (model === "user") {
          return false;
        }
        return uuidv7();
      },
    },
  },
});

Additional context

No response

Originally created by @OscarCornish on GitHub (Mar 5, 2026). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce 1. Have a user table with numeric ids 2. Create rest of tables with UUIDs generateId: ``` generateId({ model }) { if (model === "user") { return false; } return uuidv7(); }, ``` This works for creating tables, but when searching them it will throw at the adapter because "userId column expected type Int" (or similar) ### Current vs. Expected behavior I want to be able to declare for a table: - Let the db generate your id values - Those id values will be numeric But if generateIds is false, then the check for numericIds (generateId === "serial") will not be true ### What version of Better Auth are you using? 1.5.1 ### System info ```bash - ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, advanced: { database: { generateId({ model }) { if (model === "user") { return false; } return uuidv7(); }, }, }, }); ``` ### Additional context _No response_
GiteaMirror added the enhancement label 2026-03-13 10:33:27 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Mar 5, 2026):

This is a confirmed limitation in Better Auth. The useNumberId flag that determines whether userId columns should be integers or strings is set globally based on generateId === "serial" — it doesn't support per-model type detection.

The adapter factory transforms foreign key references based on this global flag:

if (fieldAttributes!.references?.field === "id" && useNumberId) {
  newValue = newValue !== null ? Number(newValue) : null;
}

When your generateId function returns false for the user model, the database correctly generates a numeric ID, but since generateId !== "serial", the adapter still expects userId to be a string — causing the type mismatch.

Current workarounds:

  1. Use generateId: "serial" globally (all tables use numeric auto-increment IDs)
  2. Use string IDs everywhere for consistency

There doesn't appear to be a way to declare per-table ID types currently — this would require framework changes to support mixed ID type configurations.

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Mar 5, 2026): <!-- Answer --> This is a confirmed limitation in Better Auth. The `useNumberId` flag that determines whether `userId` columns should be integers or strings is set globally based on `generateId === "serial"` — it doesn't support per-model type detection. The [adapter factory transforms foreign key references](https://github.com/better-auth/better-auth/blob/c15f6d9c0addd4218077f38c13be51cc17b69b42/packages/core/src/db/adapter/factory.ts#L239-244) based on this global flag: ```typescript if (fieldAttributes!.references?.field === "id" && useNumberId) { newValue = newValue !== null ? Number(newValue) : null; } ``` When your `generateId` function returns `false` for the user model, the database correctly generates a numeric ID, but since `generateId !== "serial"`, the adapter still expects `userId` to be a string — causing the type mismatch. **Current workarounds:** 1. Use `generateId: "serial"` globally (all tables use numeric auto-increment IDs) 2. Use string IDs everywhere for consistency There doesn't appear to be a way to declare per-table ID types currently — this would require framework changes to support mixed ID type configurations. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ddae3975-d9c0-4635-aa98-761ae05987c0?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20is%20a%20confirmed%20limitation%20in%20Better%20Auth.%20The%20%60useNumberId%60%20flag%20that%20determines%20whether%20%60userId%60%20columns%20should%20be%20integers%20or%20strings%20is%20set%20globally%20based%20on%20%60generateId%20%3D%3D%3D%20%22serial%22%60%20%E2%80%94%20it%20doesn%27t%20support%20per-model%20type%20detection.%0A%0AThe%20%5Badapter%20factory%20transforms%20foreign%20key%20references%5D%28https%3A//github.com/better-auth/better-auth/blob/c15f6d9c0addd4218077f38c13be51cc17b69b42/packages/core/src/db/adapter/factory.ts%23L239-244%29%20based%20on%20this%20global%20flag%3A%0A%0A%60%60%60typescript%0Aif%20%28fieldAttributes%21.references%3F.field%20%3D%3D%3D%20%22id%22%20%26%26%20useNumberId%29%20%7B%0A%20%20newValue%20%3D%20newValue%20%21%3D%3D%20null%20%3F%20Number%28newValue%29%20%3A%20null%3B%0A%7D%0A%60%60%60%0A%0AWhen%20your%20%60generateId%60%20function%20returns%20%60false%60%20for%20the%20user%20model%2C%20the%20database%20correctly%20generates%20a%20numeric%20ID%2C%20but%20since%20%60generateId%20%21%3D%3D%20%22serial%22%60%2C%20the%20adapter%20still%20expects%20%60userId%60%20to%20be%20a%20string%20%E2%80%94%20causing%20the%20type%20mismatch.%0A%0A%2A%2ACurrent%20workarounds%3A%2A%2A%0A1.%20Use%20%60generateId%3A%20%22serial%22%60%20globally%20%28all%20tables%20use%20numeric%20auto-increment%20IDs%29%0A2.%20Use%20string%20IDs%20everywhere%20for%20consistency%0A%0AThere%20doesn%27t%20appear%20to%20be%20a%20way%20to%20declare%20per-table%20ID%20types%20currently%20%E2%80%94%20this%20would%20require%20framework%20changes%20to%20support%20mixed%20ID%20type%20configurations.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/8415)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#2996