Edge cases

In this part, we will talk about the edge cases we found during the development of the project. Prisma allows different structures to define models and relations. We had to choose which to exploit and which to avoid. Some choices may evolve in the future.

Fields

id for identification

We decided to use the id field to identify the models. This field is automatically generated by Prisma and is unique. The library doesn’t support Prisma’s composite keys.

So this is the recommended way to identify models.

model User {
    id        Int      @id @default(autoincrement())
    [...]
}

Autogenerated fields

Prisma allows fields to be generated automatically. For example, the id field is automatically generated by Prisma. These fields are not editable by the user, neither during creation nor during an update.

Relations

One to one

Prisma allows one-to-one relations. But just one of the two models can have a relation field. If you want to remove the relation, you have to remove the field from the model that doesn’t have the relation field.

There is an example of a one-to-one relation between User and Profile models.

model User {
    id        Int      @id @default(autoincrement())
    profile   Profile? @relation("profile")
}
 
model Profile {
    id        Int     @id @default(autoincrement())
    bio       String?
    user      User?    @relation("profile", fields: [userId], references: [id])
    userId    Int?     @unique
}

Even if the userId field is not required, you cannot remove the relationship between User and Profile without removing the profile field from the user model.

Many to many

Prisma allows two types of many-to-many relationships: implicit and explicit. Both are supported in the library. But for better understanding in the Next Admin UI, we recommend using implicit relations.

Self relation

Prisma allows self relations. All the self relations are supported by the library.