Rails 2.1: UTC-Timestamped Migrations

Rails 2.1 introduced UTC-timestamped migrations.

What does this mean?

Prior to Rails 2.1, when you added a migration, the number would be a simple three-digit number, like so.

ruby script/generate migration create_some_table
=> create db/migrate/008_create_some_table

Imagine, now, you have a multi-developer environment. Jack’s next task is to create a migration that populates some hello-world data; so he does this:

ruby script/generate migration populate_hello_world_data
=> create db/migrate/008_populate_hello_world_data

His local application sees only 7 migrations, so it labels the next migration as 008.

Salman, on the other hand, has another task–to add created_on and updated_on fields to every single table; so he does this:

ruby script/generate migration add_created_and_updated_fields
=> create db/migrate/008_add_created_and_updated_fields

His local application sees only 7 migrations–Jack didn’t check his migration in yet! So when both of them are checked in, Rails gets confused–it sees two migrations numbered 007.

Enter UTC-timestamped migrations. Instead of a number, Rails applies a timestamp, like so:

=> create db/migrate/20081121203844_some_migration

Notice the timestamp instead of the number. This is good–it means unless two developers create a migration at the exact same second, they’ll have different timestamps. (Really, don’t argue this point–it’s easy enough to resolve this if it becomes a conflict, or to shout out “Incoming migration!” when you’re creating a migration.)

Unfortunately, for the rest of us single-developer Rails coders who don’t need UTC-timestamped migrations (or don’t know how to specify a specific version–whatever happened to rake db:migrate version=7?), you can force the old-school migration numbering system, by adding this one line to your environment.rb file:

config.active_record.timestamped_migrations = false

So enjoy! Use these new timestamped migrations if you need them–personally, I find the older migration system easier to manage. But I guess it’s a matter of choice, since I don’t need to worry about migration conflicts.

Tags: database, migrations, rails 2.1     Posted in Development, Projects

Rate this article:

(No Ratings Yet)

 Loading ...

---

Related Content

---