Exercise 2: Deleting a User Who Has Posts — Possible Solution
===============================================================

  await prisma.user.delete({ where: { email: "grace@example.com" } });

What happens: the delete fails with a foreign key constraint error
(typically reported by Prisma with the code P2003), and nothing is
deleted — not even the profile.

Why: the Post.author relation is required and has no onDelete, so it
uses the default, Restrict. The database refuses to delete a user
while posts still refer to them, because that would leave posts
pointing at an author who no longer exists. The whole delete is
rejected, so the profile's Cascade never gets a chance to run.

Two ways to make deleting a user possible:

  1. Delete (or reassign) the posts first, deliberately:
       await prisma.post.deleteMany({ where: { authorId: user.id } });
       await prisma.user.delete({ where: { id: user.id } });
     Or move the posts to another account by updating their authorId.
     Appropriate when posts are valuable and someone should decide what
     happens to them. (Prisma Intermediate/Advanced, Chapter 1, shows
     how to make these steps a single transaction.)

  2. Change the schema so the posts survive without an author:
       authorId Int?
       author   User? @relation(fields: [authorId], references: [id], onDelete: SetNull)
     Appropriate when posts should stay published after a user leaves,
     shown as "former member" or similar.

(onDelete: Cascade on Post.author would also "work", but deleting one
account would silently delete all their posts — usually not what a
blog wants.)

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the failure through the default Restrict action, notes
that the delete is all-or-nothing, and weighs the options against what
should really happen to the data.