Rails -- understanding db:migrate

I am having a little trouble understanding migrations in Ruby on Rails. I have the following two classes in my application's db\migrate\ directory (stored in separate files):

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :name
      t.string 开发者_运维问答:email

      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

class AddEmailUniquenessIndex < ActiveRecord::Migration
  def self.up
    add_index :users, :email, :unique => true
  end

  def self.down
    remove_index :users, :email
  end
end

I am confused at how these two files seem to be run together. Upon creation of this second class, Michael Hartl's book says "we could just edit the migration file for the users table but that would require rolling back then migrating back up. The Rails Way is to use migrations every time we discover that our data model needs to change." How do these migrations actually work? Are all the files in the directory run when the database is migrated? Like what is going on behind the scenes here??

As convention, the file name for these migration classes will be prefixed by a timestamp representation of when these were created (ex. 20110611000000). When you run db:migrate, rails will check a special table in the database which contains the timestamp of the last migration applied to the database. It will then apply all of the migrations with timestamps after that date and update the database table with the timestamp of the last migration. As a result, each migration class is applied exactly once to the database.

Michael Hart was illustrating that if you put all of the migrations into a single file, rails would have a hard / impossible time telling which migrations had been applied and which ones hadn't. The only option at that point would be to drop all the tables in the database and run through all the migrations from the beginning. Functionally that works, but you would lost all your data. Better to move only in the 'forward' direction than back to the beginning and then forward again.

How do these migrations actually work?

db:migrate is a rake task. The db:migrate task (a built-in Rails support program) will search through your project's db/migrate directory and use the files therein to update the database's schema.

Are all the files in the directory run when the database is migrated? No. Only the new db/migrate files (the ones that you added since the last time you ran the db:migrate command) are run when you type "rake db:migrate" on the command line.

This means that it is a bad idea (not the Rails-way) to modify any of your db/migrate files. Instead, add a new file.

Like what is going on behind the scenes here?? How Rails and db:migrate machinery keeps track of your project's db version depends on the version of Rails.

Added: Here is some good info on how migrations work under the covers.

Think of each file as a set of instructions to be run once. Basically the rake db:migrate task will load the migration object and run .up() on it. If you've already run a migration then changing the file no longer has any effect -- the migration has already run. However, changing the migrations would throw off other users of your app. So, don't change old migrations, create new ones and then only run them once.

Because migration classes are only executed once you can actually delete old migration files if you want to, but from then on if you reset your DB you'd need to run rake db:setup first before rake db:migrate ( basically the db would need to be loaded from the schema.rb file first since your migrations would no longer include all the steps required to get the database to the final state ). The files don't take up a lot of space so usually it's simpler just to leave them alone.

It is basically a programmatic front-end to a SQL interface. It keeps you from having to interact with your database directly and makes sure that you can use any database type as well (mySQL, SQLite, PostOgre)