Database Migrations in Ruby on Rails

Welcome to the next step in enhancing your Ruby on Rails ToDo application — database migrations! In this lesson, you'll dive into how Rails manages database schema changes over time. Mastering migrations ensures that your application evolves smoothly as you add enterprise-grade features or adjust complex data structures. Migrations act as version control for your database, allowing teams to share and track changes without manually running SQL scripts.

In Rails, a migration is a Ruby class that defines changes to be applied to your database. When you first set up an application, you typically start by creating tables. Here's a look at a migration file designed to create the core table for our application:

class CreateTodos < ActiveRecord::Migration[6.1]
  def change
    create_table :todos do |t|
      t.string :title
      t.text :description

      t.timestamps
    end
  end
end

This migration creates a todos table with title and description columns. The t.timestamps line automatically adds created_at and updated_at columns, which are essential for auditing and tracking data history in professional environments.

As your application grows, you will inevitably need to expand your data model. Rails migrations allow you to add columns to existing tables without losing existing data. Consider this example where we add a file attachment reference to our ToDo items:

class AddFileToTodo < ActiveRecord::Migration[6.1]
  def change
    add_column :todos, :file, :string
  end
end

Using add_column specifies the table name (:todos), the new column name (:file), and the data type (:string). This approach keeps your schema adjustments seamless and trackable across your entire development team.

Rails migrations also allow you to remove columns, but in an enterprise production environment, this requires careful strategy. Simply running a remove_column migration can cause immediate errors.

class RemoveFileFromTodo < ActiveRecord::Migration[6.1]
  def change
    remove_column :todos, :file
  end
end

The risk arises because running Rails servers cache the database schema when they boot. If you delete a column from the database while a server process is still running, that process may still attempt to query or update the old column, leading to application crashes. To handle this safely in a real-world deployment, you should first tell Rails to ignore the column in the model file, deploy that change to all servers, and only then run the migration to remove the column from the database.