why camel case instead of snakecase default for table names?

[anon-ghub]

see title

[SaulMoreno3]

Prisma intentionally keeps the TypeScript model names separate from the database naming convention. It does not automatically convert camelCase to snake_case because the model and field names are also part of the generated client API.

Map the database names explicitly when needed:

model UserProfile {
userId Int @Map("user_id")

@@Map("user_profile")
}

Then Prisma Client can use userProfile.userId while Prisma reads and writes user_profile.user_id. If you introspect an existing database, Prisma will preserve the existing database names through @Map and @@Map rather than silently renaming them.

[anon-ghub]

Thanks.

It's sort of unusual. I have been building web apps for 20 years now and almost every framework ends up using snakecase for the table names (and might automatically map to camelCase at the application level). maybe this is a combination of ease of sql querying (no need to quote table and field names) and general running convention. I'll use the workaround, but I was curious about the origin.

[SaulMoreno3]

Glad it helps! The @map and @@map escape hatch is quite handy. SQL keeps its snake_case convention while the generated client stays camelCase 😄

[luantaraschi]

There is no camelCase default, and no case conversion in either direction. The table name is the model identifier exactly as you typed it, and the column name is the field identifier exactly as you typed it. ModelWalker::database_name() returns the @@map value if one exists and otherwise falls back to the AST identifier (model.rs#L98), and ScalarFieldWalker::database_name() does the same for @map.

So this is valid, and gives you a user_profile table with a user_id column, with no @@map anywhere:

model user_profile {
  user_id Int @id @default(autoincrement())
  name    String?
}

Introspection mirrors it. A table named comments comes back as model comments.

On why PascalCase is recommended, the most I can reconstruct from the code is that the identifier does two jobs and only one of them is constrained. It is the database name, and it is also the generated TypeScript type. Model names get validated against a reserved list behind is_reserved_type_name, whose doc comment reads:

/// Is this a valid type name for the Prisma Client API?

(reserved_model_names.rs#L6). There is no database-side check at all. That asymmetry is presumably why the schema reference words it as a preference rather than a rule:

Model names must start with a letter and are typically spelled in PascalCase

I could not find Prisma stating the historical reason anywhere, so treat that paragraph as me reading the code, not as their answer.

Worth separating one thing: the quoting pain with PascalCase tables is real in psql and hand-written SQL, but it never reaches Prisma Client, because the Postgres visitor always double-quotes identifiers (postgres.rs#L62).

A global naming config has been open as #8283 since 2021. If you want to avoid hand-writing every @map, schema rewriters generate them for you: vpmedia/prisma-schema-remap and onozaty/prisma-schema-fixer are the ones currently maintained, and iiian/prisma-case-format, the one usually linked, is archived.

Which direction is your case, though? Writing a fresh schema and wanting snake_case in the database is just a matter of naming the models that way, as above. Introspecting an existing snake_case database and wanting PascalCase models in the client is the harder direction, and it is the one those tools exist for. The answer is pretty different depending on which.

Read the engine source at tag 7.9.1. I did not run a migration to confirm the emitted DDL, and did not try the third-party tools.

[anon-ghub]

Amazingly thorough answer

I have found that when you go against the grain of a library, it eventually bites you. So i will likely accept the default recommendations and not use mmap either