[GH-ISSUE #13] Possibly change user core table from name to firstname, lastname and username #8090

Closed
opened 2026-04-13 03:08:51 -05:00 by GiteaMirror · 14 comments
Owner

Originally created by @xcaeser on GitHub (Sep 28, 2024).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/13

the docs showcasing the user table:
User table

Proposal to update it to become:
username, firstname, lastname.

username being a potential combination of first letters if First and lastnames.

Potential refactoring, a lot.

Originally created by @xcaeser on GitHub (Sep 28, 2024). Original GitHub issue: https://github.com/better-auth/better-auth/issues/13 the docs showcasing the user table: [User table](https://www.better-auth.com/#user-table) Proposal to update it to become: username, firstname, lastname. username being a potential combination of first letters if First and lastnames. Potential refactoring, a lot.
GiteaMirror added the locked label 2026-04-13 03:08:51 -05:00
Author
Owner

@xKesvaL commented on GitHub (Oct 2, 2024):

I really do think the only thing that could "need" change is name -> displayName, as that is litteraly what it is.
First name and last name should be up to the user to implement.

<!-- gh-comment-id:2389628705 --> @xKesvaL commented on GitHub (Oct 2, 2024): I really do think the only thing that could *"need"* change is `name` -> `displayName`, as that is litteraly what it is. First name and last name should be up to the user to implement.
Author
Owner

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

I really do think the only thing that could "need" change is name -> displayName, as that is litteraly what it is. First name and last name should be up to the user to implement.

Since name is already used by next-auth, which is probably one of the most widely adopted library in the ecosystem, it makes sense to conform to that. But, I think displayName makes more sense too.

<!-- gh-comment-id:2390810313 --> @Bekacru commented on GitHub (Oct 3, 2024): > I really do think the only thing that could _"need"_ change is `name` -> `displayName`, as that is litteraly what it is. First name and last name should be up to the user to implement. Since `name` is already used by next-auth, which is probably one of the most widely adopted library in the ecosystem, it makes sense to conform to that. But, I think `displayName` makes more sense too.
Author
Owner

@xcaeser commented on GitHub (Oct 3, 2024):

I think we can all agree that the goal of better-auth is to be better than next-auth (which sucks to push you to use clerk)

<!-- gh-comment-id:2390814725 --> @xcaeser commented on GitHub (Oct 3, 2024): I think we can all agree that the goal of better-auth is to be better than next-auth (which sucks to push you to use clerk)
Author
Owner

@Bekacru commented on GitHub (Nov 5, 2024):

Since user fields need to be mapped to the user information returned by OAuth, we don’t always receive both firstName and lastName. And for using display name instead, OAuth2 Spec profile provides a name field for the full name, rather than a displayName or something similar. Seems fair enough to conform to that. If someone wants to have separate firstName and lastName fields, they can use additional fields for now. We also plan to allow users to define non-mandatory user fields themselves in the future. Given this, making a change now doesn’t make much sense, so I’ll close this issue.

<!-- gh-comment-id:2456397705 --> @Bekacru commented on GitHub (Nov 5, 2024): Since user fields need to be mapped to the user information returned by OAuth, we don’t always receive both `firstName` and `lastName`. And for using display name instead, OAuth2 Spec profile provides a `name` field for the full name, rather than a `displayName` or something similar. Seems fair enough to conform to that. If someone wants to have separate `firstName` and `lastName` fields, they can use additional fields for now. We also plan to allow users to define non-mandatory user fields themselves in the future. Given this, making a change now doesn’t make much sense, so I’ll close this issue.
Author
Owner

@Fefedu973 commented on GitHub (Dec 1, 2024):

It would be nice tbh to have theses fields

<!-- gh-comment-id:2510209915 --> @Fefedu973 commented on GitHub (Dec 1, 2024): It would be nice tbh to have theses fields
Author
Owner

@Bekacru commented on GitHub (Dec 1, 2024):

It would be nice tbh to have theses fields

you could still have them as additional fields

<!-- gh-comment-id:2510221976 --> @Bekacru commented on GitHub (Dec 1, 2024): > It would be nice tbh to have theses fields you could still have them as additional fields
Author
Owner

@Fefedu973 commented on GitHub (Dec 1, 2024):

How can I do that please?

<!-- gh-comment-id:2510222789 --> @Fefedu973 commented on GitHub (Dec 1, 2024): How can I do that please?
Author
Owner

@luksch42 commented on GitHub (Dec 1, 2024):

How can I do that please?

Here are the docs:
https://www.better-auth.com/docs/concepts/database#extending-core-schema

<!-- gh-comment-id:2510227557 --> @luksch42 commented on GitHub (Dec 1, 2024): > How can I do that please? Here are the docs: https://www.better-auth.com/docs/concepts/database#extending-core-schema
Author
Owner

@Fefedu973 commented on GitHub (Dec 1, 2024):

Thanks!

<!-- gh-comment-id:2510227863 --> @Fefedu973 commented on GitHub (Dec 1, 2024): Thanks!
Author
Owner

@Fefedu973 commented on GitHub (Dec 1, 2024):

And how can i integrate it directly with the Oauth response ? Thanks

<!-- gh-comment-id:2510230397 --> @Fefedu973 commented on GitHub (Dec 1, 2024): And how can i integrate it directly with the Oauth response ? Thanks
Author
Owner

@Bekacru commented on GitHub (Dec 1, 2024):

And how can i integrate it directly with the Oauth response ? Thanks

you can provide custom getUserInfo function for each provider. But we should have a better solution soon since that'd require you to fetch user data from the provider or parse the idToken yourself. There is already open issue #371

<!-- gh-comment-id:2510232026 --> @Bekacru commented on GitHub (Dec 1, 2024): > And how can i integrate it directly with the Oauth response ? Thanks you can provide custom `getUserInfo` function for each provider. But we should have a better solution soon since that'd require you to fetch user data from the provider or parse the idToken yourself. There is already open issue #371
Author
Owner

@Bekacru commented on GitHub (Dec 1, 2024):

will give it a priority the coming week :)

<!-- gh-comment-id:2510232117 --> @Bekacru commented on GitHub (Dec 1, 2024): will give it a priority the coming week :)
Author
Owner

@Fefedu973 commented on GitHub (Dec 1, 2024):

Nice thanks !

<!-- gh-comment-id:2510232456 --> @Fefedu973 commented on GitHub (Dec 1, 2024): Nice thanks !
Author
Owner

@Fefedu973 commented on GitHub (Dec 6, 2024):

Hey now that it is implemented could you please explain how to use it. I want to have separated fields for firstname and lastname, I use google and microsoft oauth which both provides these fields but idk how to link them to an additional field. thanks !

<!-- gh-comment-id:2524237917 --> @Fefedu973 commented on GitHub (Dec 6, 2024): Hey now that it is implemented could you please explain how to use it. I want to have separated fields for firstname and lastname, I use google and microsoft oauth which both provides these fields but idk how to link them to an additional field. thanks !
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#8090