Ruby on Rails allows you to do what they call ‘database migrations’, which are basically DDL and DML changes that are stored one change at a time, each in its own script. Each script contains a “migration up” (e.g. “create table X”) and a “migration down” (e.g. “drop table X”), so you can execute your change and later retract it if you made a mistake. This is really useful when:
- working with many developers at the same time, all of them coordinating making database changes
- updating your database at release time
I’ve been playing with these migrations for a few hours, so it’s not like I’m an expert, but and here are some preliminary observations:
1. Ruby on Rails, in its effort to achieve “independence” from the database will inevitably preach sketchy data organization practices while praising it as simply “making things easy.” Many articles, such as Guide to Ruby on Rails Migrations by Matt Kern will state things such as
“I consider constraints part of the business logic of the application and find that they’re easier to track if they stay in the application code and out of the database.”
To that I say: orphaned records have never done anyone any good.
While the migrations are really really cool and Ruby on Rails allows you to prototype and write fast scripts without setting up an organized access to your database, they are exactly that: a way to write quick scripts. It worries me a little that the Ruby community condones mistreatment of data organization in the name of “ease of use”.
2. Despite the above, I do like the concept of migrations, but I’m greedy and I want more, more, more! Here is my wishlist for next releases of migrations:
a. What about procedures? What if I want to revert a change to a package – would I need to store previous versions of package files to revert them? What about branching code, certain migrations for certain branches and not others?
b. How about some dependencies? I’d like to know that when I run an ‘alter table X’ statement, table X actually exists.
I’m very torn – I really really like the idea of migrations. I currently need a good database diff/update tool and “migrations” as used in Rails is a pretty simple approach that would allow many developers to work together pretty well. However, I am not about to give up referential integrity . It would hurt me greatly if I had to.
It’s probably time that I stopped whining and just wrote my own code. A script to process the migrations is simple enough (e.g. ‘rake’) – it’d be interesting to write one that would include the items on my wishlist. I’ll post progress updates as I go.
Dave
on Jul 2nd, 2007
@ 10:11 am:
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!