Schema.rb understanding in Ruby on Rails - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is schema.rb in a Rails project?

schema.rb is a file that shows the current structure of the database in Ruby code format. It helps Rails know what tables and columns exist.

beginner

How is schema.rb generated or updated?

Rails updates schema.rb automatically when you run migrations using commands like rails db:migrate. It reflects the latest database changes.

beginner

Why should you not edit schema.rb manually?

Because schema.rb is auto-generated, manual changes will be overwritten by Rails. Always change the database structure using migrations instead.

intermediate

What is the difference between schema.rb and the actual database?

schema.rb is a Ruby file that describes the database structure. The actual database stores the real data and structure. schema.rb is a snapshot, not the live database.

intermediate

How does schema.rb help when setting up a new Rails environment?

When you set up a new Rails project, you can load the database structure quickly using rails db:schema:load which uses schema.rb to create tables without running all migrations.

What command updates schema.rb in a Rails project?

A rails console

B rails server

C rails generate model

D rails db:migrate

rails db:migrate runs migrations and updates schema.rb to reflect database changes.

Which file should you edit to change the database structure in Rails?

A schema.rb

B routes.rb

C migration files

D application.rb

Database changes should be done in migration files, not schema.rb.

What does rails db:schema:load do?

A Loads database structure from <code>schema.rb</code>

B Drops the database

C Starts the Rails server

D Runs all migrations

This command creates the database structure quickly using schema.rb without running migrations.

Why is schema.rb useful in a team environment?

A It shows the current database structure for everyone

B It stores user data

C It runs the Rails server

D It contains application logic

schema.rb helps team members see the database structure without running migrations themselves.

If you manually edit schema.rb, what will happen?

A Changes will be saved permanently

B Your changes will be overwritten on next migration

C Rails will ignore migrations

D The database will update automatically

Manual edits to schema.rb get overwritten when migrations run next time.

Explain what schema.rb is and how it relates to Rails migrations.

Think about how Rails keeps track of your database tables and columns.

Describe how schema.rb helps when setting up a new Rails project on a different machine.

Consider how to quickly prepare the database without running every migration.

Practice

1. What is the main purpose of the schema.rb file in a Rails project?

easy

A. To show the current database tables and columns in Ruby code

B. To store user data permanently

C. To write application business logic

D. To manage user sessions

Solution

1. Step 1: Understand the role of schema.rb

   The schema.rb file represents the database structure in Ruby code format.

2. Step 2: Differentiate from other files

   It does not store data or application logic but shows tables and columns for easy sharing and recreation.

3. Final Answer:

   To show the current database tables and columns in Ruby code -> Option A

4. Quick Check:

   schema.rb = database structure [OK]

Hint: Remember: schema.rb maps database structure only [OK]

Common Mistakes:

• Thinking schema.rb stores actual data
• Confusing it with migration files
• Assuming it contains app logic

2. Which of the following is the correct syntax to define a string column named title in schema.rb?

easy

A. t.string :title

B. t.column :title, :integer

C. t.text 'title'

D. t.integer :title

Solution

1. Step 1: Identify correct column type syntax

   In schema.rb, string columns use t.string :column_name syntax.

2. Step 2: Check options

   t.string :title uses t.string :title, which is correct for a string column named title.

3. Final Answer:

   t.string :title -> Option A

4. Quick Check:

   String column syntax = t.string :title [OK]

Hint: Use t.string :name for string columns [OK]

Common Mistakes:

• Using t.integer for string columns
• Using quotes instead of symbols
• Confusing t.text with t.string

3. Given this snippet from schema.rb:

create_table "books", force: :cascade do |t|
  t.string "name"
  t.integer "pages"
  t.timestamps
end

What columns will the books table have?

medium

A. name (string), pages (string), timestamps (string)

B. name (string), pages (integer) only

C. name (string), pages (integer), created_at (datetime), updated_at (datetime)

D. name (text), pages (integer), timestamps (boolean)

Solution

1. Step 1: Read column definitions

   The table has name as string, pages as integer, and t.timestamps adds created_at and updated_at datetime columns.

2. Step 2: Confirm column types

   So columns are: name (string), pages (integer), created_at (datetime), updated_at (datetime).

3. Final Answer:

   name (string), pages (integer), created_at (datetime), updated_at (datetime) -> Option C

4. Quick Check:

   t.timestamps adds created_at and updated_at [OK]

Hint: Remember t.timestamps adds two datetime columns [OK]

Common Mistakes:

• Ignoring t.timestamps columns
• Assuming pages is string
• Confusing column types

4. You see this line in schema.rb but your migration added a price column as decimal:

t.integer :price

What is the likely problem?

medium

A. The price column is missing from the database

B. The migration syntax is wrong and created an integer column

C. Rails does not support decimal columns

D. The migration used decimal but schema.rb shows integer, so schema.rb is outdated

Solution

1. Step 1: Compare migration and schema types

   The migration added price as decimal, but schema.rb shows integer, indicating it was not updated.

2. Step 2: Understand schema.rb update process

   schema.rb updates only after running migrations successfully; if not updated, it shows old info.

3. Final Answer:

   schema.rb is outdated and shows integer instead of decimal -> Option D

4. Quick Check:

   Run migrations to update schema.rb [OK]

Hint: If types differ, check if migrations were run properly [OK]

Common Mistakes:

• Assuming Rails lacks decimal support
• Thinking migration syntax is always wrong
• Ignoring need to run migrations

5. You want to add a new published boolean column with default false to your articles table. After creating and running the migration, what will schema.rb show for this column?

hard

A. t.boolean :published

B. t.boolean :published, default: false

C. t.integer :published, default: 0

D. t.string :published, default: 'false'

Solution

1. Step 1: Understand migration effect on schema.rb

   Adding a boolean with default false will be reflected as t.boolean :published, default: false in schema.rb.

2. Step 2: Eliminate incorrect options

   t.boolean :published misses default, C uses wrong type integer, D uses string type incorrectly.

3. Final Answer:

   t.boolean :published, default: false -> Option B

4. Quick Check:

   Boolean with default shows type and default in schema.rb [OK]

Hint: Boolean defaults appear explicitly in schema.rb [OK]

Common Mistakes:

• Omitting default value in schema.rb
• Using wrong data type for boolean
• Confusing string and boolean types