wess•3d ago

Should I use `users` table or `profiles`?

Should I use users table from Convex Auth for storing additional user data, or should I better create profiles table and store it there, not touching the users table? Which one is considered a best practice for Convex Auth?

7 Replies

Convex Bot•3d ago

Thanks for posting in <#1088161997662724167>. Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets. - Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.) - Use search.convex.dev to search Docs, Stack, and Discord all at once. - Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI. - Avoid tagging staff unless specifically instructed. Thank you!

erquhart•3d ago

Totally fine to customize that table, there’s a guide in the docs: https://labs.convex.dev/auth/setup/schema

Customizing Schema - Convex Auth

Authentication library for your Convex backend

TripleSpeeder•2d ago

I also chose to customize the users table, prevents lots of boilerplate code and I don't see any harm in it. Only thing that would be nice if there was a way to extend the default scheme with something like spread operator.

const schema = defineTable({
  ...users,
  myCustomFields
})

const schema = defineTable({
  ...users,
  myCustomFields
})

Or is there a way? Right now I I just copied everything from the convex auth users schema and added my own fields.

ballingt•2d ago

Does this not work? Maybe it's

const schema = defineTable({
  ...users.fields,
  myCustomFields
})

const schema = defineTable({
  ...users.fields,
  myCustomFields
})

oh right I think it's

const schema = defineTable({
  ...users.validator.fields,
  myCustomFields
})

const schema = defineTable({
  ...users.validator.fields,
  myCustomFields
})

or similar

erquhart•2d ago

yeah it's the second one I'm actually curious why the docs say to inline them, wonder if we're missing something here. I just switched to spread, will update if I encounter issues, but the types look right. I bet it's to avoid implicit changes to the schema from auth lib updates which... yeah I'm going to back to inlining them lol

ballingt•2d ago

We'll hit a level of stable at some point where we say "if we ever add a new field here we will start with it optional in one release, give you a migration to run, and in the next release it'll be required"

TripleSpeeder•17h ago

For this scenario I'm thinking it's probably better to just use the dedicated userProfile table. Assuming that when auth lib requires changes to the schema it will anyway not work properly when only updating code but not the schema... But I trust in @Tom and team that we will get proper docs and migration path for this case (once the lib is stable) 🙂