Explain Prisma schema code

What this Prisma schema sample shows

models and fields

Each model becomes a table and each field a column, written as name, type, then attributes, except relation fields like author and posts, which link tables instead of storing a value. prisma migrate diff turned model User into CREATE TABLE "User". name String? became "name" TEXT and a new user with no name stored NULL; without the ? it became "name" TEXT NOT NULL.

attributes

@id marks the primary key and @default(autoincrement()) gives each new row the next number: the first user got id 1. @unique on email became a unique index: adding a second ana@example.com failed with UNIQUE constraint failed: User.email. @default(now()) became DEFAULT CURRENT_TIMESTAMP, which filled createdAt, and @default(false) left a new post unpublished.

relations

author User @relation(...) says authorId holds a User's id, and became a foreign key: a post for user 99, who doesn't exist, failed with FOREIGN KEY constraint failed. posts Post[] is the other side, a list with no column of its own. Without it, prisma validate stopped: the relation field author is missing an opposite relation field on the model User.

the generator and datasource

generator client tells prisma generate to write the code your app uses to query the database: it wrote client.ts and the files next to it into src/generated/prisma, the output folder. datasource db names the database type, here SQLite. In Prisma 7 the address the command line tool uses lives in prisma.config.ts, and your app passes its own connection to new PrismaClient(): with url = env("DATABASE_URL") added here, prisma validate stopped, saying the datasource property url is no longer supported in schema files.

Good to know

• Run with Prisma 7.10.1 and SQLite 3.53.4: prisma validate passed, prisma migrate diff --from-empty printed the SQL, and that SQL was run against an empty SQLite file with foreign keys switched on.
• onDelete: Cascade made the foreign key ON DELETE CASCADE: deleting a user with 2 posts left 0 posts. With it taken out, Prisma wrote ON DELETE RESTRICT instead, and deleting a user who still had a post failed and left the user in place.

Watch out: Changing this file doesn't change your database. The tables only change when you run a command such as prisma migrate dev or prisma db push, and your app's query code only changes when prisma generate runs. Before applying a migration, read the SQL it will run: making name required became "name" TEXT NOT NULL, which a table that already has users without a name can't hold.