Exercise 1: Two Ways to Rename a Field — Possible Solution
============================================================

Way 1: rename the column in the database

schema.prisma:
  body String?          // was: content String?

  $ npx prisma migrate dev --name rename-content-to-body --create-only

Generated SQL (would destroy every post's text):
  ALTER TABLE "Post" DROP COLUMN "content",
  ADD COLUMN "body" TEXT;

Edited SQL:
  ALTER TABLE "Post" RENAME COLUMN "content" TO "body";

  $ npx prisma migrate dev
  $ npx prisma generate      # code now uses post.body

Way 2: keep the column, rename only in Prisma

schema.prisma:
  body String? @map("content")

No migration SQL is needed — the database is unchanged. Running
"npx prisma migrate dev" reports nothing to migrate (or creates an
empty migration, which you can delete). Regenerate the client and the
code uses post.body.

Which one for an app with several copies running?

@map. During a rolling deploy, old and new copies run side by side.
With Way 1, the moment the migration runs, the old copies' queries for
"content" fail until they're replaced. With Way 2 the column never
changes, so old and new code work against the same database at the
same time.

If you really do want the column itself renamed without downtime, do
it with expand and contract: add "body", write to both, backfill, read
from "body", stop writing "content", then drop it.

WHY THIS WORKS AS AN ANSWER
------------------------------
It shows why the default migration is dangerous (drop + add, not a
rename), fixes it the way Prisma's docs recommend, and compares it with
@map, which changes only the code-side name. The choice is justified by
the real constraint of a live app: several versions running at once.