Jao's migrations compare against the live database, not against a migration history; it introspects the database. So there's no "previous state" recorded anywhere.
It should maintain a full model state graph built from the migration chain. Each migration knows the complete before/after state. Reversals are trivial because you have both states.
While we may add previousType/previousDefault for reversals to work for the code generator (since it has both the model schema and the DB schema at diff time), it adds complexity to ColumnModification that only serves reverse code generation — no other consumer needs it.
Building a migration state graph seems the way to go but that's a major architectural change.
Jao's migrations compare against the live database, not against a migration history; it introspects the database. So there's no "previous state" recorded anywhere.
It should maintain a full model state graph built from the migration chain. Each migration knows the complete before/after state. Reversals are trivial because you have both states.
While we may add previousType/previousDefault for reversals to work for the code generator (since it has both the model schema and the DB schema at diff time), it adds complexity to
ColumnModificationthat only serves reverse code generation — no other consumer needs it.Building a migration state graph seems the way to go but that's a major architectural change.