Exercise 2: Why on_delete=CASCADE Would Be Dangerous Here — Possible Solution
====================================================================

WHAT CASCADE WOULD ACTUALLY DO
------------------------------
Per this chapter, Django's own default for a ForeignKey is on_delete=CASCADE - deleting a parent row silently deletes every one of its children too, recursively, all the way down the tree. Applied to the Page model's self-referential parent field, deleting a single subject-level page (like "Programming") would silently cascade-delete every category, subcategory, course, and chapter underneath it - potentially hundreds of pages - in one single delete operation, with no confirmation step or intermediate warning about how much content was actually about to be removed.

WHY THIS IS "GENUINELY DANGEROUS" SPECIFICALLY
------------------------------
Per this chapter, deleting one page by mistake could wipe out an entire subject's worth of course chapters without any warning - the danger isn't that cascading deletes are always wrong, it's that the scale of an accidental cascade here is effectively unbounded and invisible until it's already happened, since the admin performing the delete has no reason to expect a single click to remove an entire subtree.

WHY PROTECT IS THE FIX
------------------------------
Per this chapter, on_delete=PROTECT instead refuses the deletion outright while children still exist, forcing a deliberate decision (delete the children first, or reparent them) rather than allowing an accidental cascade to happen silently.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains what CASCADE would actually do to the Page model's self-referential structure (silent, recursive, unbounded deletion), correctly explains why that's dangerous specifically for this use case (an entire subtree gone with no warning), and correctly names PROTECT as the safer alternative this chapter chose instead.