Names in the underlying database

The Prisma schema includes mechanisms that allow you to define names of certain database objects. You can:

Mapping collection/table and field/column names

Sometimes the names used to describe entities in your database might not match the names you would prefer in your generated API. A common approach for naming tables/collections in databases for example is to use plural form and snake_case notation. Prisma on the other hand has recommended model naming conventions (singular form, PascalCase) which differ from that. Mapping names in the Prisma schema allows you to influence the naming in your Client Api without having to change the underlying database names.

Map collection / table names

For example, when you introspect a database with a table named comments, the resulting Prisma model will look like this:

model comments {
// Fields
}

However, you can still follow the naming convention without renaming the underlying comments table in the database by using the @@map attribute:

model Comment {
// Fields
@@map("comments")
}

With this modified model definition, Prisma automatically maps the Comment model to the comments table in the underlying database.

Map field / column names

You can also @map a column/field name:

model Comment {
content String @map("comment_text")
email String @map("commenter_email")
type Enum @map("comment_type")
@@map("comments")
}

Map enum names and values

You can also @map an enum value, or @@map an enum:

enum Type {
Blog,
Twitter @map("comment_twitter")
@@map("comment_source_enum")
}

@map and @@map allow you to tune the shape of your Prisma Client API by decoupling model and field names from table and column names in the underlying database.

Constraint and index names

In 2.29.0 and later, you can use the map argument to define the underlying constraint and index names in the Prisma schema. This means the @id, @@id, @unique, @@unique, @index and @relation attributes now take an optional argument called map. The map argument will only be rendered in the schema if you use a name that differs from Prisma's naming convention.

Additionally, the @@id and @@unique attributes take an optional name argument that allows you to customize your Prisma client API.

Specifying @@id([firstName, lastName], name: "fullName") will allow you to do

prisma.user.findUnique({
where: { fullName: { firstName: 'Paul', lastName: 'Panther' } },
})

instead of:

prisma.user.findUnique({
where: { firstName_lastName: { firstName: 'Paul', lastName: 'Panther' } },
})

Not supported by MongoDB
Custom constraint and index names are currently not supported by MongoDB.

If you use Prisma Migrate and want to maintain your existing constraint and index names, do not immediately run prisma migrate or prisma db push. This will change any underlying constraint name that does not follow Prisma's convention. Follow the upgrade path for the Prisma Migrate workflow.

Use cases for named constraints

Some use cases for explicitly named constraints include:

  • Company policy
  • Conventions of other tools

Using default constraint names

The following schema defines three constraints (@id, @unique, and @relation) and one index (@@index):

model User {
id Int @id @default(autoincrement())
name String @unique
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
title String
authorName String @default("Anonymous")
author User? @relation(fields: [authorName], references: [name])
@@index([title, authorName])
}

Since no explicit names are provided via map arguments Prisma will assume they follow our default naming convention.

Prisma's default naming conventions for indexes and constraints

If you introspect a database the names for indexes and constraints will be added to your schema unless they follow Prisma's naming convention. If they do, the names are not rendered to keep the schema more readable. When you migrate such a schema Prisma will infer the default names and persist them in the database.

We chose our naming convention to align with Postgre s since it is deterministic and helps us maximize the amount of times where we do not need to render names because they already align with the convention.

We always use the database names of entities when generating the default names. So if a model is remapped to a different name in the datamodel, the default name generation will still take the name of the table in the db as input. The same is true for fields and columns.

EntityConventionExample
Primary Key{tablename}_pkeyUser_pkey
Unique Constraint{tablename}_{column_names}_keyUser_firstName_last_Name_key
Non-Unique Index{tablename}_{column_names}_idxUser_age_idx
Foreign Key{tablename}_{column_names}_fkeyUser_childName_fkey

Since most databases have a length limit for entity names, the names will be trimmed if necessary to not violate the database limits. We will shorten the part before the _suffix as necessary so that the full name is at most the maximum length permitted.

Using custom constraint / index names

You can use the map argument to define custom constraint and index names in the underlying database. The following example adds custom names to one @id and the @@index:

model User {
id Int @id(map: "Custom_Primary_Key_Constraint_Name") @default(autoincrement())
name String @unique
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
title String
authorName String @default("Anonymous")
author User? @relation(fields: [authorName], references: [name])
@@index([title, authorName], map: "My_Custom_Index_Name")
}

The following table lists the name of each constraint and index in the underlying database:

Constraint or indexFollows conventionUnderlying constraint or index names
@id (on User > id field)NoCustom_Primary_Key_Constraint_Name
@@index (on Post)NoMy_Custom_Index_Name
@id (on Post > id field)YesPost_pk
@relation (on Post > author)YesPost_authorName_fkey
Edit this page on GitHub