3 ms·

> There’s no reason higher level frameworks or ORMs couldn't handle the migration process. > ...this is a manual painful process today, but theres no reason th

> There’s no reason higher level frameworks or ORMs couldn't handle the migration process. > ...this is a manual painful process today, but theres no reason this can’t be fully handled by PostgreSQL or directly within an ORM . You mean like EF already does [1]? > Add-Migration will scaffold the next migration based on changes you have made to your model since the last migration was created For what it's worth, I don't use that feature. I prefer to use SQL Server Data Tools [2] to maintain a model of the database and use its schema and data diff tools to generate upgrade scripts. This is more due to the database pre-dating EF migrations but as well the schema is fairly complex so having SSDT (with its knowledge of nearly all SQL Server object types) do diffs against the actual database model is better than EF diffing its own abstract model. [1] http://msdn.microsoft.com/en-us/data/jj591621.aspx http://msdn.microsoft.com/en-us/data/jj591621.aspx [2] http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).a...

samstokes 13y ago
The Haskell database-mapping library [1] "persistent" does auto-migrations as well. You declare your data types in a DSL reminiscent of SQL CREATE TABLE statements. If you add a new data type, it creates the table; if you add a field, it adds the column; if you make a field optional, it changes the column to allow nulls. It will only do that for non-destructive changes, so if you remove a column (which would lose data), or make an optional field non-optional (which is ill-defined if you had NULLs), it bails out with a message suggesting the SQL you should run to migrate manually. [1] I can't really call it an ORM, since it maps to Haskell record types rather than _O_bjects, and it works with NoSQL databases as well as _R_elational databases.
elchief 13y ago
Hibernate and EclipseLink do migrations for you too.
politician 13y ago
In my experience, these tools never handle complex migrations well. Renaming a column? You might drop the production data, and add a column initialized to its defaults. My approach is to maintain a stack of diffs to the schema in DDL that are hand-crafted and checked into source control, so that when it inevitably fails during QA there isn't a 2MB SQL diff to hunt through to figure out why.

samstokes 13y ago

The Haskell database-mapping library [1] "persistent" does auto-migrations as well. You declare your data types in a DSL reminiscent of SQL CREATE TABLE statements. If you add a new data type, it creates the table; if you add a field, it adds the column; if you make a field optional, it changes the column to allow nulls. It will only do that for non-destructive changes, so if you remove a column (which would lose data), or make an optional field non-optional (which is ill-defined if you had NULLs), it bails out with a message suggesting the SQL you should run to migrate manually. [1] I can't really call it an ORM, since it maps to Haskell record types rather than _O_bjects, and it works with NoSQL databases as well as _R_elational databases.

elchief 13y ago

Hibernate and EclipseLink do migrations for you too.

politician 13y ago

In my experience, these tools never handle complex migrations well. Renaming a column? You might drop the production data, and add a column initialized to its defaults. My approach is to maintain a stack of diffs to the schema in DDL that are hand-crafted and checked into source control, so that when it inevitably fails during QA there isn't a 2MB SQL diff to hunt through to figure out why.