Exercise 1: The Self-Referencing Schema — Possible Solution
====================================================================

THE SCHEMA
------------------------------
Per this chapter, the Page model in prisma/schema.prisma is:

model Page {
  id        Int     @id @default(autoincrement())
  slug      String
  fullPath  String  @unique
  title     String
  body      String? @db.Text

  parentId  Int?
  parent    Page?   @relation("PageHierarchy", fields: [parentId], references: [id], onDelete: Restrict)
  children  Page[]  @relation("PageHierarchy")
}

WHY THE NAMED RELATION IS REQUIRED
------------------------------
Page references itself twice - once as parent (the "one" side) and once
as children (the "many" side). Without a shared relation name, Prisma
has no way to tell these two fields describe the same relationship
viewed from opposite ends, rather than two separate, unrelated
relations. "PageHierarchy" (or any consistent string) ties them
together explicitly.

RUNNING THE MIGRATION
------------------------------
npx prisma migrate dev --name init
diffs the schema against the (empty) migration history, writes a new
SQL migration file creating the Page table with its self-referencing
foreign key and ON DELETE RESTRICT clause, and applies it to the
database in one step.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly includes both halves of the self-referencing relation with
a matching relation name, includes the onDelete: Restrict clause on the
parent side (not the children side, which is where this chapter's own
schema places it), and runs the actual migration command rather than
just writing the schema file without applying it.