Why Changing column types in Ruby on Rails? - Purpose & Use Cases

The Big Idea

What if changing your database columns could be as easy as writing a single line of code?

The Scenario

Imagine you have a database table with a column storing dates as strings. Now you want to change that column to a proper date type to run date calculations.

You try to update the database manually by writing raw SQL commands or editing the schema directly.

The Problem

Manually changing column types is risky and slow. You might forget to convert existing data properly, causing errors or data loss.

Also, manual changes are hard to track and share with your team, leading to confusion and bugs.

The Solution

Rails migrations let you change column types safely and clearly. They handle data conversion and keep a history of changes.

This means you can update your database structure with simple, readable code that everyone on your team can understand and use.

Before vs After

✗ Before

ALTER TABLE users ALTER COLUMN birthdate TYPE date USING birthdate::date;

✓ After

change_column :users, :birthdate, :date

What It Enables

You can evolve your database structure smoothly as your app grows, without breaking data or confusing your team.

Real Life Example

A social app starts storing user birthdays as text but later needs to calculate age. Changing the column type to date with a migration makes this easy and safe.

Key Takeaways

Manual column type changes are error-prone and hard to track.

Rails migrations provide a safe, clear way to change column types.

This helps keep your database consistent and your team in sync.

Practice

1.

What is the primary Rails method used to change the type of an existing database column in a migration?

easy

A. change_column

B. rename_column

C. add_column

D. remove_column

Solution

1. Step 1: Understand migration methods

   Rails migrations provide specific methods for altering tables. add_column adds new columns, remove_column deletes columns, and rename_column changes column names.

2. Step 2: Identify method for changing column type

   The method change_column is designed to change the type of an existing column without removing it.

3. Final Answer:

   change_column -> Option A

4. Quick Check:

   Change column type = change_column [OK]

Hint: Use change_column to modify column types in migrations [OK]

Common Mistakes:

• Confusing change_column with rename_column
• Trying to use add_column to change type
• Using remove_column instead of changing type

2.

Which of the following is the correct syntax to change a column named price to type decimal with precision 8 and scale 2 in a Rails migration?

class ChangePriceTypeInProducts < ActiveRecord::Migration[7.0]
  def change
    ?
  end
end

easy

A. change_column :products, :price, :decimal, precision: 8, scale: 2

B. change_column :products, :price, :decimal(8,2)

C. change_column :products, :price, :decimal, {precision: 8, scale: 2}

D. change_column :products, :price, :decimal, precision => 8, scale => 2

Solution

1. Step 1: Review change_column syntax

   The correct syntax uses symbol keys for options: change_column(table, column, type, options). Options like precision and scale are passed as keyword arguments.

2. Step 2: Identify correct option format

   change_column :products, :price, :decimal, precision: 8, scale: 2 correctly uses precision: 8, scale: 2 as keyword arguments. change_column :products, :price, :decimal(8,2) uses invalid syntax. change_column :products, :price, :decimal, {precision: 8, scale: 2} uses a hash but without keyword arguments. change_column :products, :price, :decimal, precision => 8, scale => 2 uses hash rockets which is invalid in this context.

3. Final Answer:

   change_column :products, :price, :decimal, precision: 8, scale: 2 -> Option A

4. Quick Check:

   Keyword args for options = change_column :products, :price, :decimal, precision: 8, scale: 2 [OK]

Hint: Use keyword arguments for options in change_column [OK]

Common Mistakes:

• Using parentheses in type declaration like :decimal(8,2)
• Passing options as a hash without keywords
• Using old hash rocket syntax in options

3.

Given this migration snippet, what will be the new type of the age column after running it?

class ChangeAgeTypeInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :age, :string
  end
end

medium

A. integer

B. boolean

C. string

D. float

Solution

1. Step 1: Read the change_column call

   The method call changes the age column in the users table to type :string.

2. Step 2: Understand the effect

   After running the migration, the age column will store string values instead of its previous type.

3. Final Answer:

   string -> Option C

4. Quick Check:

   change_column to :string = string [OK]

Hint: Look at the third argument of change_column for new type [OK]

Common Mistakes:

• Assuming the type stays the same
• Confusing column name with type
• Thinking change_column renames columns

4.

What is wrong with this migration code that tries to change a column type?

class ChangeActiveToBooleanInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :active, 'boolean'
  end
end

medium

A. The column name should be a string, not a symbol

B. The type should be a symbol, not a string

C. change_column cannot change to boolean type

D. The migration class name is invalid

Solution

1. Step 1: Check argument types in change_column

   The method expects the type argument as a symbol, e.g., :boolean, not a string.

2. Step 2: Identify the error

   Using a string like 'boolean' will cause a syntax or runtime error because Rails expects symbols for types.

3. Final Answer:

   The type should be a symbol, not a string -> Option B

4. Quick Check:

   Type argument must be symbol = The type should be a symbol, not a string [OK]

Hint: Use symbols (e.g., :boolean) for types in change_column [OK]

Common Mistakes:

• Passing type as a string instead of symbol
• Thinking change_column can't handle boolean
• Misnaming migration class

5.

You want to change a column rating from integer to decimal with precision 3 and scale 1, but keep existing data safe. Which approach is best?

hard

A. Use change_column :table, :rating, :decimal, precision: 3, scale: 1 directly in one migration

B. Change the column type in the database manually without migration

C. Drop the column and add a new decimal column with the same name

D. Create a new decimal column, copy data with conversion, then remove old column and rename new one

Solution

1. Step 1: Understand risks of direct change_column

   Directly changing column type can cause data loss or errors if existing data doesn't fit new type.

2. Step 2: Use safe migration strategy

   Creating a new column, copying data with conversion, then removing old column and renaming new one ensures data safety and rollback ability.

3. Final Answer:

   Create a new decimal column, copy data with conversion, then remove old column and rename new one -> Option D

4. Quick Check:

   Safe type change = create-copy-rename [OK]

Hint: Avoid direct type change; copy data safely first [OK]

Common Mistakes:

• Directly changing type risking data loss
• Dropping column without backup
• Changing DB manually without migration