Exercise 3: Why the Alembic Gap Is Structural, Not an Oversight — Possible Solution
====================================================================

THE CHAPTER'S OWN TWO KEY QUOTES
------------------------------------------------
Data Mapper (Chapter 6, SQLAlchemy's own docs): "The ORM considers the
user-defined class, the associated table metadata, and the mapping of
the two to be entirely separate."

Alembic (this chapter): "a database migrations tool written by the
author of SQLAlchemy" -- a genuinely separate real package, with its
own alembic.ini and its own versions/ directory.

WHY THE SEPARATION IS STRUCTURAL, NOT ACCIDENTAL
------------------------------------------------------------
A migration tool's real job is to compare the database's current real
structure against the structure the application's own models describe,
and generate the real ALTER statements needed to close the gap. That
job only has one clean, natural home inside a framework if the
framework itself already treats "what the models say" and "what the
database actually looks like" as one single, tightly coupled concept
-- so tightly coupled that a tool built to reconcile the two can live
right next to the models themselves without stepping outside anything
the ORM already owns.

SQLAlchemy's own real design goes the opposite direction on purpose:
the mapped class, the table metadata, and the mapping between them are
kept "entirely separate," per its own quoted documentation. There's no
single, unified "this is the model, this is the truth" object for a
migration tool to hang off of the way Django's models.Model or Rails'
ApplicationRecord provide -- building real migration tooling directly
into SQLAlchemy would mean reaching across a boundary the ORM's own
architecture was specifically designed to keep separate. Alembic
existing as its own real package, maintained by the same author, isn't
a gap SQLAlchemy failed to fill -- it's the natural, structural result
of a design that never created one unified place for such a tool to
live inside the ORM itself.

WHY DJANGO AND ACTIVERECORD NEVER FACED THIS QUESTION AT ALL
------------------------------------------------------------------
Both are real, quoted Active Record systems: a Django model both
defines the schema AND knows how to save itself (per Chapter 6's own
quoted "each model is a Python class that subclasses
django.db.models.Model"), and ActiveRecord's own class is directly
mapped to the table it represents, per its own quoted "wraps a row in
a database table, encapsulates the database access." Because the model
class already IS the single, unified representation of both the data
shape and the persistence behavior, a migration tool comparing "what
the models say" against "what the database looks like" has one
obvious, natural home to live in -- directly inside the same framework
that already owns both halves of that comparison. The design decision
that makes Data Mapper's own separation valuable (keeping persistence
logic out of the domain class) is the exact same decision that leaves
migrations with no natural home inside the ORM -- and Active Record's
own opposite decision (fusing the two together) is what gives Django
and Rails a natural home for migrations that SQLAlchemy's own design
never had in the first place.

WHY THIS WORKS AS AN ANSWER
----------------------------
It traces the real gap back to a specific, quoted design decision
(Data Mapper's own "entirely separate" mapping) rather than treating
it as an unexplained fact, and directly contrasts it against Django's
and ActiveRecord's own quoted Active Record design to explain why the
identical structural question never arose for either of them.