github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 08:01:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #132] Suggestion: improve consistency across IDs #25465

New Issue
Closed
opened 2026-04-17 15:41:56 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-17 15:41:56 -05:00
Owner
Copy Link

Originally created by @rokitgg on GitHub (Oct 9, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/132

Description

Currently, there are inconsistencies in the string length of user and table IDs across the API. This can led to unexpected situations when, for example, a certain column might only allow for a maximum amount of characters to be inserted.

Imagine this scenario using drizzle-orm:

const users = pgTable("user", (t) => ({
   id: t.char({ length: 21 }).primaryKey();
  })
// some insert operations might fail while others don't!

Current Situation

I've observed varying approaches to ID generation across different parts of the codebase. For example:

  1. In user creation:

    const createdUser = await ctx.context.internalAdapter.createUser({
  id: generateRandomString(32, alphabet("a-z", "0-9", "A-Z")),
  // ...other fields
});

  2. In a general ID generation function (utils/id.ts), where the default is set to 21 characters:

    export const generateId = (size?: number) => {
  return generateRandomString(size || 21, alphabet("a-z", "0-9", "A-Z"));
};

Proposal

  1. Implement a common ID generation function that is used consistently across the entire codebase (already exists).
  2. Decide on a fixed length for IDs (e.g., 32 characters) to ensure uniformity.

Benefits

  • Improved code consistency and readability
  • Simplified database operations and queries
  • Reduced potential for conflicts or errors due to ID inconsistencies
  • Easier maintenance and debugging

Questions for Discussion

  • Is there a specific reason for the current variation in ID lengths?
Originally created by @rokitgg on GitHub (Oct 9, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/132 ### Description Currently, there are inconsistencies in the string length of user and table IDs across the API. This can led to unexpected situations when, for example, a certain column might only allow for a maximum amount of characters to be inserted. Imagine this scenario using drizzle-orm: ```typescript const users = pgTable("user", (t) => ({ id: t.char({ length: 21 }).primaryKey(); }) // some insert operations might fail while others don't! ``` ### Current Situation I've observed varying approaches to ID generation across different parts of the codebase. For example: 1. In user creation: ```typescript const createdUser = await ctx.context.internalAdapter.createUser({ id: generateRandomString(32, alphabet("a-z", "0-9", "A-Z")), // ...other fields }); ``` 2. In a general ID generation function (utils/id.ts), where the default is set to 21 characters: ```typescript export const generateId = (size?: number) => { return generateRandomString(size || 21, alphabet("a-z", "0-9", "A-Z")); }; ``` ### Proposal 1. Implement a common ID generation function that is used consistently across the entire codebase (already exists). 2. Decide on a fixed length for IDs (e.g., 32 characters) to ensure uniformity. ### Benefits - Improved code consistency and readability - Simplified database operations and queries - Reduced potential for conflicts or errors due to ID inconsistencies - Easier maintenance and debugging ### Questions for Discussion - Is there a specific reason for the current variation in ID lengths?
GiteaMirror added the locked label 2026-04-17 15:41:56 -05:00
GiteaMirror commented 2026-04-17 15:41:58 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Oct 9, 2024):

Great suggestions! The variation was caused because we're refactoring to use generateId for all ID-related generations. I've just opened a PR that should address the issue.

<!-- gh-comment-id:2403298523 --> @Bekacru commented on GitHub (Oct 9, 2024): Great suggestions! The variation was caused because we're refactoring to use generateId for all ID-related generations. I've just opened a PR that should address the issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#25465
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?