Creating migrations in Ruby on Rails - Practice Exercises

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the effect of this migration code?

Consider this Rails migration code snippet:

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

What will be the result after running this migration?

Ruby on Rails

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

A Creates a new table called 'age' with integer type

B Removes the 'age' column from 'users' table

C Changes the 'age' column type to string in 'users' table

D Adds an integer column 'age' to 'users' table with default value 18 for new records

💡 Hint

Think about what add_column does and the effect of default value.

The migration adds a new integer column named 'age' to the existing 'users' table. The default: 18 means new records will have age set to 18 unless specified otherwise.

📝 Syntax

intermediate

Which migration code will create a table with a primary key?

You want to create a new table 'products' with columns 'name' (string) and 'price' (decimal). Which migration code correctly creates this table with an id primary key?

A

create_table :products do |t|
  t.string :name
  t.decimal :price
end

B

create_table :products, id: false do |t|
  t.string :name
  t.decimal :price
end

C

create_table :products, primary_key: :product_id do |t|
  t.string :name
  t.decimal :price
end

D

create_table :products, id: true do |t|
  t.string :name
  t.decimal :price
end

💡 Hint

By default, create_table adds an id primary key unless id: false is specified.

Option A creates the table with the default primary key 'id'. Option A disables the id column. Option A tries to set a custom primary key but syntax is incorrect. Option A is valid but redundant because id: true is default and does not need to be specified.

🔧 Debug

advanced

Why does this migration raise an error?

Given this migration:

class ChangePriceTypeInProducts < ActiveRecord::Migration[7.0]
  def change
    change_column :products, :price, :string
  end
end

Running this migration raises an error. What is the cause?

Ruby on Rails

class ChangePriceTypeInProducts < ActiveRecord::Migration[7.0]
  def change
    change_column :products, :price, :string
  end
end

A The :string type is invalid for change_column

B change_column cannot be used inside the change method because it is irreversible

C The migration file is missing a version number in the class inheritance

D The :price column does not exist in the products table

💡 Hint

Think about whether change_column can be reversed automatically.

change_column is not reversible by default, so it should be used inside up/down methods or with reversible blocks. Using it inside change causes an error.

❓ state_output

advanced

What is the state of the database after this migration?

After running this migration:

class CreateOrders < ActiveRecord::Migration[7.0]
  def change
    create_table :orders do |t|
      t.references :user, null: false, foreign_key: true
      t.timestamps
    end
  end
end

Which statement is true about the 'orders' table?

Ruby on Rails

class CreateOrders < ActiveRecord::Migration[7.0]
  def change
    create_table :orders do |t|
      t.references :user, null: false, foreign_key: true
      t.timestamps
    end
  end
end

A The 'orders' table has no timestamps columns

B The 'orders' table has a 'user' column storing user names

C The 'orders' table has a 'user_id' column with a foreign key constraint to 'users' table

D The 'orders' table has a 'user_id' column but no foreign key constraint

💡 Hint

t.references adds a column with _id suffix and foreign_key: true adds a constraint.

t.references :user adds a 'user_id' integer column. foreign_key: true adds a database foreign key constraint linking to users table. t.timestamps adds created_at and updated_at columns.

🧠 Conceptual

expert

What happens if you rollback a migration that adds a column with default value?

You run a migration that adds a column 'status' with default 'pending' to 'tasks' table. Then you rollback this migration. What is the state of the 'tasks' table after rollback?

A The 'status' column is removed from the 'tasks' table

B The 'status' column remains but default value is removed

C The 'status' column remains with default 'pending'

D The rollback fails because default values cannot be removed

💡 Hint

Rollback reverses the migration changes, removing added columns.

Rolling back a migration that adds a column removes that column entirely, including any default values. The table returns to its previous state.