feat(drizzle-adapter): custom database's tables naming strategy

[skyf0l]

NOTE:

• It's a good idea to open an issue first to discuss potential changes.
• Please make sure that you are NOT opening a PR to fix a potential security vulnerability. Instead, please follow the Security guidelines to disclose the issue to us confidentially.

☕️ Reasoning

I'm migrating my database from Prisma to Drizzle, but I got a problem using drizzle adapter cause table names are different (camelCase vs PascalCase). So, I added an option to force the naming strategy 🚀

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

Please scout and link issues that might be solved by this PR.

Fixes: INSERT_ISSUE_LINK_HERE

📌 Resources

• Security guidelines
• Contributing guidelines
• Code of conduct
• Contributing to Open Source

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
auth-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 12, 2024 10:13am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
next-auth-docs	⬜️ Ignored (Inspect)	Visit Preview		Jan 12, 2024 10:13am

[vercel]

@skyf0l is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[skyf0l]

Up?

[GLips]

I'm in a similar boat, migrating from Prisma to Drizzle and about to copy my own DrizzleAdapter out to make these modifications.

[nhedger]

Hey @skyf0l, I'm wondering whether giving the option to use either one of PascalCase, camelCase or snake_case would be a better idea. I'd be willing to help implement this. What is your take on this?

[skyf0l]

Hey @skyf0l, I'm wondering whether giving the option to use either one of PascalCase, camelCase or snake_case would be a better idea. I'd be willing to help implement this. What is your take on this?

Hey @nhedger, first it was to keep consistency with the Prima adapter, then to avoid renaming tables in my production database just because of an ORM switch in my main application.

As the Drizzle adapter is new, I think it's a good idea to start keeping consistency between them all.

Finally, even though some database table names are case insensitive, not all are (e.g. PlanetScale).

In any case, the main goal is consistency :)

(ATM, we use a fork of the Drizzle adapter to avoid renaming our tables.)

[nhedger]

I understand that; my reasoning was that some users may prefer to use a different case. For example, all my tables use snake_case, so for the sake of consistency, I'd like these tables to use snake_case too, hence my proposition to make it configurable.

If you personally don't need this, I'd fully understand if you did not want to invest time in it and can submit a PR of my own.

[skyf0l]

Oh, I read it sideways, yes indeed your suggestion is definitely the best!
I should have 5 minutes in the week to update this quickly!

[nhedger]

Glad to hear; let me know if you need any assistance.

[felixnorden]

+1 on what you both have said @nhedger @skyf0l , we have a project where the tables are in camelCase and so are the fields in JS-land, but in SQL they are snake_case, so starting to work towards allowing the user to configure the naming scheme (as the docs state other adapters do) would be grand.
Let me know if you need any help as well!

[skyf0l]

I've synchronized my fork with the upstream 🚀

[ormarek]

Im not in actual power here to accept or reject those changes you've made, but wanted to make a small suggestion

You could create a small naming table like:

const names = {
  snake_case: {
    userId: "user_id",
    ...
  },
  camelCase: {
    userId: "userId",
    ...
  },
  pascalCase: {
    userId: "UserId",
    ...
  }
}

and then instead of doing tedious trenary everywhere (which is also typo prone) you could use names[namingStrategy].<name> e.g. names[namingStrategy].userId

[ndom91]

In general this looks good to me, tests are still passing too!

@balazsorban44 @ThangHuuVu we had something similar with another db adapter in the past, but I can't remember the details. I think technically this is good to go, yall okay with this generally?

[ndom91]

Btw see this PR that adds support for custom tables and seems to ahve a lot of overlap: #8561

[nahtnam]

I have no authority here but just want to chime in that I prefer the other PR over this one. I want to do snake_case but pluralize and I dont think this PR would support that. I assume future developers might want totally different names or a prefix for the table names. It would be better instead to just allow us to pass the schemas as options