Changing column types in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

📝 Syntax

intermediate

Correct syntax for changing a column type in Rails migration

Which option correctly changes the column type of age from integer to string in a Rails migration?

Ruby on Rails

class ChangeAgeTypeInUsers < ActiveRecord::Migration[7.0]
  def change
    # change column type here
  end
end

A change_column :age, :users, :string

B change_column :users, :age, :string

C change_column_type :age, :users, :string

D change_column_type :users, :age, :string

💡 Hint

Remember the order: table name, column name, then new type.

The change_column method takes the table name first, then the column name, and finally the new type.

Options A, B, and C use incorrect method names or argument orders.

❓ component_behavior

intermediate

Effect of changing column type on existing data

What happens to existing data in the price column when you change its type from integer to string using change_column in Rails migration?

A Existing integer values are converted to strings preserving their values

B Existing data is deleted and the column is emptied

C Migration fails with a type mismatch error

D Existing data remains as integers and causes runtime errors

💡 Hint

Think about how databases handle type casting during column changes.

When changing a column type from integer to string, the database converts existing integer values to their string representations.

Data is preserved but converted.

🔧 Debug

advanced

Identify the error in this migration changing column type

What error will this migration raise when run?

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

Ruby on Rails

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

A ActiveRecord::StatementInvalid: invalid type for default value

B ArgumentError: unknown keyword: default

C SyntaxError: unexpected keyword_end

D No error, migration runs successfully

💡 Hint

Check the allowed options for change_column method.

No error. The change_column method accepts default as an option.

To change only the default without changing type, use change_column_default separately.

❓ state_output

advanced

Resulting schema after changing column type with null constraint

After running this migration, what will be the null constraint on the email column?

class ChangeEmailTypeInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :email, :text, null: false
  end
end

Ruby on Rails

class ChangeEmailTypeInUsers < ActiveRecord::Migration[7.0]
  def change
    change_column :users, :email, :text, null: false
  end
end

A The <code>email</code> column will NOT allow null values

B The <code>email</code> column will allow null values

C The migration will fail with an error about null constraint

D The null constraint remains unchanged from before migration

💡 Hint

Does change_column support changing null constraints directly?

The change_column method supports the null option, setting the column to NOT allow null values.

For nullability-only changes, prefer change_column_null for better reversibility across databases.

🧠 Conceptual

expert

Best practice for changing column type with data migration

You need to change a column type from string to integer but existing data may not convert cleanly. What is the best approach to handle this safely in Rails migrations?

A Drop the table and recreate it with the new column type

B Use <code>change_column</code> directly and fix data errors later

C Create a new column with the new type, migrate data manually, then remove old column

D Change the column type in the database manually outside Rails

💡 Hint

Think about data safety and rollback ability.

Changing column types directly can cause data loss or errors if data doesn't convert cleanly.

Best practice is to add a new column, migrate and clean data manually, then remove the old column.

This approach is safer and reversible.