Cookin' with Ruby on Rails - May
Pages: 1, 2, 3, 4, 5, 6

Paul:  Well, at least I can tell it did something this time.

CB:  Yep.  It created a directory and, within it, our first migration.  Before we take a look at that, though, let's have a look at the schema file.

Initial schema.rb file
Figure 10. (Click to enlarge.)

Paul:  Well that looks pretty much like the SQL script we started with.

CB:  Yep.  That's exactly right and exactly what we wanted.  Rails now knows what our initial database looks like and how to create it.  Notice the comment at the top.  If we'd started from scratch, rather than with an existing database structure with content we want to preserve, we would not modify this file.  In fact, this is really the only time we'll make a modification to this file ourselves.  Since we started with an existing database, though, we need to make one modification here so that Rails can "catch up."  Basically, we're going to tell Rails that we're starting with an existing database by telling it which migration file matches this schema.  To do that, we're going to modify the schema definition line to include the version number.

Adding version number to definition
Figure 11. (Click to enlarge.)

CB:  So now we've told Rails that the "001_" migration file contains the instructions needed to migrate to this version of the schema. And now that we've done that, we can do our last step, which will "synch everything up."  We go back into the command window and enter:

rake db:migrate

Synching everything up
Figure 12. (Click to enlarge.)

Paul:  OK.  It doesn't look like it did much.  You said we're telling it which migration file to use so it could synch up.  Say more about that, would you?  How do we know it's "synched up"?

CB:  Good questions.  Let's start by taking another look at the database.

Database updated with schema_info table
Figure 13. (Click to enlarge.)

CB:  Notice anything different?

Paul:  Yeah.  What's that new schema_info table?

CB:  Rails created that.  It will use it from now on to keep track of the current version of our database schema.  Every time we run a migration, Rails looks at the content of the single field in the single record in that table to tell it the version of our current schema. Then it uses that to determine which of the migration files in our db\migrate directory it needs to run.  Let's take a look at the migration file we generated for our baseline schema.

Content of initial migration
Figure 14. (Click to enlarge.)

Paul:  It's basically empty!  What's up with that?

CB:  Remember, we started with an existing database that we wanted to preserve.  So to get back to where we started, we don't need to do any thing.  What this is telling Rails is: "If we run our first migration and we're already at Version 1 of the schema, don't do anything."

Paul:  How does Rails know it's our first migration?  Is it because of the name you gave it?

CB:  No.  The name doesn't matter to Rails.  You can name it anything you want.  I try to name them as descriptively as I can because the names help me keep track of what each migration is doing to the database.  Rails uses the number that it attaches as the prefix to whatever you called the migration when you generated it.  Let's take another look at the file it generated a minute ago.

Result of first migration
Figure 15.

Pages: 1, 2, 3, 4, 5, 6

Next Pagearrow