Exercise 1: Where the Schema Actually Lives, Three Ways — Possible Solution
====================================================================

DJANGO
------------------------------
Per this chapter, Django's Page model class declares its own fields directly (title = models.CharField(...), and so on) - the model class itself IS the schema definition, and the migration file is auto-generated FROM that class by makemigrations.

PRISMA (NEXT.JS)
------------------------------
Per this chapter, Prisma works the same fundamental way as Django on this point - schema.prisma declares the fields directly, and a migration is generated from that schema file. The schema file itself is the source of truth, migrations are a derived artifact.

LARAVEL
------------------------------
Per this chapter, Laravel inverts this relationship entirely. The migration file (hand-written PHP, using Schema::create() and Blueprint) is the real, authoritative definition of what columns the table actually has. The Eloquent model class (Page.php) does NOT redeclare those columns anywhere - it only defines $fillable (which columns can be mass-assigned), relationships (parent(), children()), and behavior (like the saving event). Reading the model class alone would not tell you what columns the table has; you have to read the migration for that.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that Django and Prisma both treat their own model/schema file as the authoritative column definition with migrations generated from it, and correctly explains that Laravel reverses this - the migration is authoritative, and the Eloquent model deliberately doesn't repeat the column definitions at all.