Rails Migrations for Beginners

I hadn’t heard of the idea of migrations until I started using Rails.

They are something that make so much sense once they make sense.

They aren’t hard to grasp but if you are new to Rails or only have to deal with Rails on an incredibly irregular basis they can be very daunting.

I want to try and explain what migrations are for beginners.

What Are Migrations

Migrations are a set of commands that Rails will run through when it is setting up or changing the database for your project.

These commands will help to shape the database.

Why Are Migrations Good

There are a few reasons why migrations are good.

• The language they use is easier than SQL
• The changes can be version controlled
• The changes can be rolled back

Migrations use a Ruby Domain Specific Language (dsl), which is easier to learn and write than it is writing SQL. The other benefit of this dsl is that it acts as an abstraction so you don’t need to care about what your database is when you write your migrations. This means that if someone decides Postgres is better than MySQL for a project, your migrations won’t have to change.

Unlike when you just edit a database, these migrations are code that gets saved with the rest of your project, which means they can be easily version controlled and shared with everyone else on your team. If you have ever had to edit a database and then remember to tell everyone to make the same edit then you will know how great this is! If you are not using version control you should take a minute to read why I think developers should be using version control.

Migrations can be rolled back, this means that you can undo what you did. This is a great safety mechanism and means you don’t have to worry about permanent damage being done.

How to use Migrations

The easiest way to write migrations is to get Rails to do it for you.

We can tell rails we want to create a table called bobs with the following command: rails generate migration createBobs name:string

This will create a table called bobs with one column called name that will hold stuff that is a string.

That seems like magic – it is magic!

Rails knew we wanted to create a new table because we used the word create, it also knew we wanted to call the table bobs because we said Bobs

Now lets say we want to then add another column to this bobs table. We could go back and edit the file that was created when we did that first creation, but that would be bad because Rails will think it has already ran that migration and won’t run it again for other people.

What we should do is just create a new migration: rails generate migration addColourToBobs colour:string

In this migration we are saying we want to add a column called Colour to the table called bobs.

For reference here is the contents of the file we made when we created that first migration;

class CreateBobs < ActiveRecord::Migration
  def change
    create_table :bobs do |t|
      t.string :name
    end
  end
end

Hopefully this isn’t too daunting and shows how simple this dsl is compared to writing SQL.

Here is the next migration we created;

class AddColourToBobs < ActiveRecord::Migration
  def change
    add_column :bobs, :colour, :string
  end
end

In both of these you will see some similarities.

• The class name is just what we called our migration.
• The class inherits from ActiveRecord::Migration – This isn’t important for us but Rails needs it.
• The method change means that when we are running the migration it knows to do one thing, and if we are rolling back the migration it knows to the do opposite (so if we are doing add_column the opposite would be to remove_column, Rails handles all this for us)