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.

Practice

1. Why does Rails use version numbers in database migrations?

easy

A. To track which migrations have been applied to the database

B. To speed up database queries

C. To store user data securely

D. To create backups automatically

Solution

1. Step 1: Understand migration purpose

   Migrations change the database structure over time.

2. Step 2: Role of version numbers

   Version numbers help Rails know which migrations ran and which are pending.

3. Final Answer:

   To track which migrations have been applied to the database -> Option A

4. Quick Check:

   Migration versioning = tracking applied changes [OK]

Hint: Version numbers track applied migrations, not data or speed [OK]

Common Mistakes:

• Thinking version numbers speed up queries
• Confusing versioning with data storage
• Assuming version numbers create backups

2. Which of the following is the correct way Rails names migration version numbers?

easy

A. A user-defined name without numbers

B. A random string of letters

C. A timestamp prefix like 20240612123456_create_users.rb

D. A hash of the migration content

Solution

1. Step 1: Identify Rails migration naming

   Rails uses timestamps to order migrations chronologically.

2. Step 2: Confirm correct format

   Migration files start with a timestamp like 20240612123456 followed by a descriptive name.

3. Final Answer:

   A timestamp prefix like 20240612123456_create_users.rb -> Option C

4. Quick Check:

   Migration version = timestamp prefix [OK]

Hint: Look for timestamp prefix in migration filenames [OK]

Common Mistakes:

• Thinking version is random letters
• Ignoring the timestamp format
• Assuming user names migrations without numbers

3. Given these migrations applied in order:
20240601010101_create_users.rb
20240602020202_add_email_to_users.rb
What will Rails do if you run rails db:migrate again without new migrations?

medium

A. It will apply all migrations again

B. It will skip migrations because they are already applied

C. It will delete the database

D. It will raise an error about duplicate migrations

Solution

1. Step 1: Understand migration tracking

   Rails records applied migrations by their version numbers in a special table.

2. Step 2: Behavior on re-running migrations

   If no new migrations exist, Rails skips already applied ones to avoid duplicate changes.

3. Final Answer:

   It will skip migrations because they are already applied -> Option B

4. Quick Check:

   Applied migrations are skipped on rerun [OK]

Hint: Rails skips migrations already recorded as applied [OK]

Common Mistakes:

• Thinking migrations run twice
• Expecting database deletion
• Assuming errors on duplicate versions

4. You created a migration file but forgot to update its version timestamp. What problem will this cause when running rails db:migrate?

medium

A. Rails will ignore the migration because the version conflicts

B. Rails will apply the migration twice

C. Rails will raise a syntax error

D. Rails will rename the migration automatically

Solution

1. Step 1: Understand version uniqueness

   Each migration version must be unique to track changes properly.

2. Step 2: Effect of duplicate version

   If two migrations share the same version, Rails ignores the second to avoid conflicts.

3. Final Answer:

   Rails will ignore the migration because the version conflicts -> Option A

4. Quick Check:

   Duplicate versions cause ignored migrations [OK]

Hint: Duplicate timestamps cause migrations to be ignored [OK]

Common Mistakes:

• Expecting automatic renaming
• Thinking Rails applies duplicates
• Assuming syntax errors from version conflicts

5. You have two developers creating migrations simultaneously. Developer A creates 20240612120000_add_age_to_users.rb and Developer B creates 20240612120000_add_status_to_users.rb. What issue arises and how should it be resolved?

hard

A. Rails will run only the first migration and ignore the second permanently

B. Rails merges both migrations automatically without issues

C. One migration overwrites the other silently

D. Both migrations have the same version causing conflicts; rename one with a unique timestamp

Solution

1. Step 1: Identify version conflict

   Both migrations share the exact same timestamp version, which must be unique.

2. Step 2: Resolve conflict

   To fix, rename one migration file with a different timestamp so Rails can track both separately.

3. Final Answer:

   Both migrations have the same version causing conflicts; rename one with a unique timestamp -> Option D

4. Quick Check:

   Unique timestamps prevent migration conflicts [OK]

Hint: Ensure unique timestamps when multiple developers create migrations [OK]

Common Mistakes:

• Assuming Rails merges migrations automatically
• Thinking one migration overwrites the other silently
• Believing Rails ignores second migration permanently