20150514090000_create_teachers.rb

class CreateTeachers < ActiveRecord::Migration
  def change
    create_table :teachers do |t|
      t.string :name
    end
  end
end

20150514090002_add_email_to_teachers.rb

class AddEmailToTeachers < ActiveRecord::Migration
    def change
        add_column :teachers, :email, :string
        add_index :teachers, :email
        add_index :teachers, :name
    end
end

notes.md

Week 3 Day 4 Notes

One of the things that AR had from Day1 (Rails 1.2 at least) is something called Migrations.

In apps with dbs, every dev has their own copy of the db.

Problem:

New features and updates to (web) apps that uses DBs may require not only code changes but also database structural/schema changes.

If you make those changes manually using a SQL tool or editor. Of course you then modify the code so it uses the new schema and implements the new feature.

You push the code to github.

What happens next?

Some other developer pulls master and has the new code. But it doesn't have any record of the DB changes.

Now the second developer has to rerun the same SQL schema changes on their local db. WTF

Solution:

Make database changes incrementally via migrations which are part of the source code (ruby / activerecord code).

Migrations are ruby files that are not run by your app, but rather by developers one time to make those one times structural changes to their db.

Workflow

1. Dev A creates a new migration file with the create_table and other changes
2. Dev A runs the migration against their own local db (rake db:migrate)
3. Dev A makes the appropriate code changes
4. Dev A is done with the feature change and pushes the code + new migration file
5. Dev B pulls
6. Dev B notices new migration files in the pull
7. Dev B runs rake db:migrate same as Dev A did
8. Dev B's rake command notices the new migration file and runs the create_table on her db
9. Dev B's code and db are now same as Dev A's

Additional Info

Once a migration runs, it is not going to run again on the same db. Unless of course you drop and recreate the db (rake db:drop and rake db:create) first.

We discovered that AR remembers this via a table called schema_migrations that it inserts into every time it runs a migration succesfully. This table keeps track of the ID's of the migrations that have already been run. It determines that there is a migration that HASN'T been run yet by finding a filename that begins with an ID that is greater than the last migration that was recorded. This is why we name migration files using the date format YYYYMMDDHHMMSS_create_teachers.rb. This ensures that the ID (the date) is always increasing in value as we add migrations.

The up method is what's executed in a migrate. The down method (not used today) is what's executed in a rollback.

There's a change method that is newer and for simpler migrations so you don't have to manually write a down. Fancier / more magic for certain situations.