Exercise 1: Applying the Blog Schema and Reading the SQL — Possible Solution
==============================================================================

  $ npx prisma validate          # "The schema ... is valid"
  $ npx prisma format            # lines up the columns
  $ npx prisma migrate dev --name blog-schema
  $ npx prisma generate

A likely snag: the User table already contains Ada from Chapter 2, and
the new schema adds a required updatedAt column with no default.
Existing rows would have no value for it, so Prisma warns you and may
offer to reset the development database (deleting its data). In a
development database with test data that's fine — accept it. Chapter 4
explains why, and how to avoid this with real data.

Reading prisma/migrations/<timestamp>_blog-schema/migration.sql, you
should find SQL along these lines (SQLite):

  CREATE TABLE "Post" (
      "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,   <- @id @default(autoincrement())
      "title" TEXT NOT NULL,                             <- required String
      "content" TEXT,                                    <- String? (no NOT NULL)
      "published" BOOLEAN NOT NULL DEFAULT false,        <- @default(false)
      "viewCount" INTEGER NOT NULL DEFAULT 0,            <- @default(0)
      "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,  <- @default(now())
      "updatedAt" DATETIME NOT NULL,                     <- @updatedAt
      ...
  );
  CREATE UNIQUE INDEX "Post_slug_key" ON "Post"("slug"); <- @unique

Two things worth noticing:

  - @updatedAt has no DEFAULT in the SQL. Prisma Client fills it in
    itself on every create and update; the database doesn't.
  - @unique becomes a unique index, not a column option.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects each schema attribute to the SQL it produces, which is
the best way to understand what the schema really means, and it flags
the reset prompt the change is likely to trigger. The exact SQL
differs between databases and Prisma versions.