Thursday, January 17, 2008

Modifying Migrations

As I continue my study of RubyOnRails using Build Your Own Ruby On Rails Web Applications by Patrick Lenz, I'm including expansions on certain topics that piqued my interest. First, here are a few useful links if you're reading the book too.









I learned a little bit more about how rake handles automatic migrations today. I suspected that like it's similarly named counterpart rake might determine which migrations to apply based on the last change date of the migration file. I was wrong.

I had created a new migration to add a column to one of my models. I ran rake and everything went without a hitch. Then, about two minutes later, I realized that I still needed to add one more column to that particular model. I didn't want to create another migration file for the second new column. "No problem," I reasoned. "I'll just add a new column to my latest migration file." I did this, ran rake, and nothing! As it turns out, rake doesn't care a bit about the time stamp on the migration file. What rake does keep track of is the last migration applied. It does this by looking at a table that rails inserts into your database. The name of the table is schema_info. The (only?) record in the table stores the number of the latest migration that was applied.

So, I did what I probably should have done in the first place. I used:


rake db:migrate VERSION 7

to move back to the previous migration. When I did this, the affects of applying the current migration, (adding a new column), were undone. Then, I modified my migration file to add the second new column and ran

rake db:migrate

rake now saw that there was a migration ahead of the one being used and re-applied my new migration file.

Please add your questions and comments/corrections to the comments below! Thanks!

No comments: