Why migrations version the database in Ruby on Rails - Visual Breakdown

Concept Flow - Why migrations version the database

Create Migration File

↓

Run Migration

↓

Migration Applies Changes

↓

Record Version in Schema Migrations Table

↓

Database Knows Which Migrations Ran

↓

Future Runs Skip Applied Migrations

This flow shows how Rails migrations apply changes and record their version to track what has been done.

Execution Sample

Ruby on Rails

class AddAgeToUsers < ActiveRecord::Migration[7.0]
  def change
    add_column :users, :age, :integer
  end
end

This migration adds an 'age' column to the 'users' table and records its version when run.

Execution Table

Step	Action	Version Recorded	Database State	Next Migration Status
1	Migration file created with timestamp 20240610120000	None yet	No 'age' column in 'users'	Pending
2	Run migration 20240610120000	20240610120000	'age' column added to 'users'	Applied
3	Check schema_migrations table	Contains 20240610120000	Database schema up to date	No re-run needed
4	Run migrations again	No new versions recorded	No changes made	Skipped already applied

💡 All migrations applied; database version matches recorded migrations.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
schema_migrations	[]	["20240610120000"]	["20240610120000"]	["20240610120000"]
users table columns	[:id, :name, :email]	[:id, :name, :email, :age]	[:id, :name, :email, :age]	[:id, :name, :email, :age]

Key Moments - 2 Insights

Why does Rails store migration versions in the database?

Rails records migration versions in the schema_migrations table to know which migrations have run, so it doesn't apply the same migration twice. See execution_table step 3.

What happens if you run migrations again after all are applied?

Rails checks the recorded versions and skips migrations already applied, avoiding duplicate changes. See execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is recorded in the schema_migrations table after step 2?

A Migration file name

B None

C 20240610120000

D Empty array

💡 Hint

Check the 'Version Recorded' column at step 2 in the execution_table.

At which step does the database schema include the new 'age' column?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Database State' column in the execution_table.

If the migration version was not recorded, what would happen on the next run?

A Migration would be skipped

B Migration would run again and add duplicate columns

C Rails would throw an error

D Nothing would change

💡 Hint

Refer to the purpose of schema_migrations in variable_tracker and key_moments.

Concept Snapshot

Rails migrations have unique version numbers.
When a migration runs, Rails applies changes and records the version in the database.
This prevents running the same migration twice.
Rails checks recorded versions before applying migrations.
This keeps the database schema in sync and avoids errors.

Full Transcript

Rails migrations use version numbers to track changes to the database schema. When you create a migration, it gets a timestamp version. Running the migration applies the changes and records this version in the schema_migrations table inside the database. This record helps Rails know which migrations have already run. If you run migrations again, Rails skips those already applied, preventing duplicate changes. This system keeps your database schema consistent and safe from repeated migrations.