If you thought migrations couldn't get any sexier, then clearly you haven't been following the mudslide of updates going on in Rails this year. As of late I've been updating tables in almost every way possible in several applications. From simply renaming columns to renaming entire tables and their dozens of loyal has_many's, I've gotten used to the old way to change tables, but I certainly haven't enjoyed it. Behold, migrations in 2.1 now allow you to do this:
I am definitely excited about that change and look forward to updating tables with the utmost ease. Along with this great update, migrations are now automatically generated with a timestamp as their version number instead of simply an integer. What this means to the solo developer is more information given at a glance than just the migration order (not too useful). What it means as a team developer is little to no worries of colliding migration versions with others on your team. Additionally, a schema_migrations table is created in your database which tells you what migrations have been run so far, which is more useful than the schema_info table which is just the latest migration version. Those of you who hate reconciling migrations with other developers rejoice.
For more on these updates, click on over to Railscasts, since I shamelessly stole an image of their screencast anyway.
What might go wrong when you update your own app, you might wonder?
In most cases there are no complications, unless you already have a migration up to version 20080605122345 [YMMV on the timestamp]. This is NOT ok if you're setting the time and date of "right now" in the application. For example, the date of present time is set to midnight, May 15th, 2007 in an app I'm currently working on for development and testing purposes. This means my new migrations (ALL of them) are given the same version of 20070515000000_.... and this is bad news. I am hunting around for a way to tell the generator to use simple version numbers instead and I will report back when said way is found.