A Review of Rails Migrations: Concepts to Remember

Today I want to review Rails migrations, specifically some important concepts you’ll at least want to familiarize yourself with if you haven’t already. Rails makes it very easy to get a project up and running quickly, and really streamlines the whole process. I’m going to highly suggest you use Active Record as your ORM (object-relational mapping) framework so you don’t have to write custom code for your models, and because it allows you to utilize common CRUD/REST conventions that most developers use nowadays. Active Record is included by default in every new Rails app, so I’m going to assume you’re just using it. Let’s get into the good stuff.

The first thing I want to go over is using scale and precision with a column that has a data type of decimal. Let’s look at this example.

class CreateOrders < ActiveRecord::Migration[6.0]  
 def change    
    create_table :orders do |t|      
    
      t.decimal :amount, precision: 10, scale: 2
      t.timestamps   
    end
  end
end

Running this migration will make it so that you can have 2 digits after the decimal point, and 10 digits total. This is helpful when you’re working with data that’ll be calculating very specific numbers. You can also indicate scale and precision straight from the command line.

rails generate migration CreateOrders amount:decimal{10.2}
#precision: 10, scale: 2

Another important component to migrations is setting up relationships between your resources. This can be done with the references keyword. Here is an example.

rails g resource Article author:references

That command will generate this migration below, along with a bunch of other files.

class CreateArticles < ActiveRecord::Migration[6.0]
def change    
   create_table :articles do |t|      
    
      t.references :author, null: false, foreign_key: true
      t.timestamps   
    end
  end
end

This is setting up a has_many and belongs_to relationship between Article and Author. An Author has_many articles, and an Article belongs_to an author. You could have also written the generator like this.

rails g resource Article author_id:integer

Which would create this migration file.

class CreateArticles < ActiveRecord::Migration[6.0]
def change    
   create_table :articles do |t|      
    
      t.integer :author_id
      t.timestamps   
    end
  end
end

In both examples you’re setting up the same relationship. There’s an author_id column in your articles table that establishes how they’re connected. One thing to be aware of is that if you’re going to be pushing your project to Heroku you might run into problems if you use the references method. Their website wants you to explicitly define the ids in your table relationships.

These are just a few concepts to keep in mind as you build out your next project. There are many different ways to structure your app and data. You’re free to use whatever works best for you, but it’s important to be aware of all your options. Rails is an incredible framework that makes building an application straightforward, and uncomplicated. I’ve loved working with it, and there’s always something new to explore. Plus the documentation is really well written. If you have an other questions about Rails migrations or anything else, go look there: https://guides.rubyonrails.org/.