I'm kicking around some ideas for a more structured approach to migrations. Something between modeling ORM Entity changes to dynamically build migrations and the current state of Goose which is just a migration is just any SQL. Currently all migrations can change anything they want in any order. In some cases this can cause problems that require developers to maybe split common changes into another migration script or reorder some migrations to deal with dependencies.
I thinking that an approach that helps organize and order SQL migrations could offer some benefits.
For example, by separating SQL by type (stored proc, table, view, etc) or by affected table you could:
order things correctly (all stored procs, all table creates/alters, all views, etc)
keep changes for a particular table together in one place to easily reconstruct the history of the table
post process table migrations to create a single up to date create table statement to view the current schema and to create new databases more quickly
order and re-order table migrations based on foreign keys (dependency tracking)
Basically by making the unit of work smaller and more structured we can make it potentially much easier to read the migrations as they'll be nicely categorized by type / table but you'll also be able to make the tool smarter and capable of merging work from many developers.
I'm kicking around some ideas for a more structured approach to migrations. Something between modeling ORM Entity changes to dynamically build migrations and the current state of Goose which is just a migration is just any SQL. Currently all migrations can change anything they want in any order. In some cases this can cause problems that require developers to maybe split common changes into another migration script or reorder some migrations to deal with dependencies.
I thinking that an approach that helps organize and order SQL migrations could offer some benefits.
For example, by separating SQL by type (stored proc, table, view, etc) or by affected table you could:
Basically by making the unit of work smaller and more structured we can make it potentially much easier to read the migrations as they'll be nicely categorized by type / table but you'll also be able to make the tool smarter and capable of merging work from many developers.