http://maggienelson.com/2007/06/ruby-on-rails-migrations-good-idea-with-a-crazy-philosophy/ databases and code goodness Sat, 28 Aug 2010 21:51:25 -0400 http://wordpress.org/?v=2.9.2 hourly 1 http://maggienelson.com/2007/06/ruby-on-rails-migrations-good-idea-with-a-crazy-philosophy/comment-page-1/#comment-10 Dave Mon, 02 Jul 2007 15:11:10 +0000 http://maggienelson.com/blog/?p=13#comment-10 Fortunately Rails doesn't force the willy-nilly attitude on you, but its available as a tradeoff. If you can forgo Rails' syntactical sugar (i.e. create_table :foo, ... ; add_column :foo, :bar) and are willing to commit to a single vendor (or omit vendor extensions), then you can just go ahead and write SQL statements using migrations. You would need to store versions of your procedures/packages, sure, but that's not so hard. The biggest benefit of migrations is that you get to ignore prod for a while, make a bazillion changes in dev, then when you're ready, its incredibly easy to apply them to prod. You can even rollback your migrations so dev and prod match, and then roll them forward at once to reassure yourself that they'll work. Its an easy way to give structure to DDL modifications, and there's not much overhead. I find the value of the syntactical sugar to be questionable, but then again I have the luxury of using my favorite DB. PS - Regarding "know that ... table X actually exists", since migrations are strictly ordered, if you create migration #5 to alter the table, you can look at the state of the DB in migration #4 and judge from there. What about errors you say? Well, that's why you test your migrations against your dev db! Fortunately Rails doesn’t force the willy-nilly attitude on you, but its available as a tradeoff. If you can forgo Rails’ syntactical sugar (i.e. create_table :foo, … ; add_column :foo, :bar) and are willing to commit to a single vendor (or omit vendor extensions), then you can just go ahead and write SQL statements using migrations. You would need to store versions of your procedures/packages, sure, but that’s not so hard.
The biggest benefit of migrations is that you get to ignore prod for a while, make a bazillion changes in dev, then when you’re ready, its incredibly easy to apply them to prod. You can even rollback your migrations so dev and prod match, and then roll them forward at once to reassure yourself that they’ll work.
Its an easy way to give structure to DDL modifications, and there’s not much overhead. I find the value of the syntactical sugar to be questionable, but then again I have the luxury of using my favorite DB.
PS – Regarding “know that … table X actually exists”, since migrations are strictly ordered, if you create migration #5 to alter the table, you can look at the state of the DB in migration #4 and judge from there. What about errors you say? Well, that’s why you test your migrations against your dev db!

]]>