Exercise 3: Confirming onDelete: Restrict Is a Real Database Constraint — Possible Solution
====================================================================

THE TEST
------------------------------
Per this chapter, the claim to verify is that ON DELETE RESTRICT is
enforced by the database itself, not just by Prisma Client's own
application-level logic. The way to confirm that honestly is to bypass
Prisma Client entirely and issue a raw SQL DELETE directly - e.g.
through prisma.$executeRawUnsafe('DELETE FROM "Page" WHERE id = $1',
parentId), or by connecting with a plain SQL client (psql/mysql CLI)
and running the same DELETE by hand - against a page row that still has
at least one child row pointing at it via parentId.

EXPECTED RESULT
------------------------------
The DELETE fails with a real foreign key constraint violation error
raised by the database engine itself (e.g. Postgres' own "violates
foreign key constraint" error), not a Prisma-level validation message.
Because the request never went through Prisma Client's own query
pipeline at all, the only thing that could have stopped it is the
database's own ON DELETE RESTRICT clause on the generated foreign key.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly deliberately bypasses Prisma Client - the whole point of
the test is to prove the constraint doesn't depend on Prisma's own code
running at all - and correctly predicts a database-level error rather
than an application-level one, which is exactly the distinction this
chapter draws between onDelete: Restrict (database-level, like
Laravel/Astro/Express) and Django's PROTECT or Rails' own
dependent: :restrict_with_error (both application-level, and both would
have let a bypassing raw DELETE through undetected).