CRUD operations through models in Ruby on Rails - Step-by-Step Execution

Concept Flow - CRUD operations through models

Create Model Instance

↓

Save to Database

↓

Read from Database

↓

Update Model Attributes

↓

Save Changes

↓

Delete Model Instance

↓

End

This flow shows how a model instance is created, saved, read, updated, and deleted in Rails.

Execution Sample

Ruby on Rails

user = User.new(name: "Alice")
user.save
user = User.find_by(name: "Alice")
user.name = "Alice Smith"
user.save
user.destroy

This code creates a user, saves it, reads it back, updates the name, and then deletes the user.

Execution Table

Step	Action	Model State	Database State	Result
1	User.new(name: "Alice")	User instance with name='Alice', not saved	No user record	Instance created in memory
2	user.save	User instance saved	User record with name='Alice' created	User saved to DB
3	User.find_by(name: "Alice")	User instance with name='Alice' loaded	User record with name='Alice' exists	User loaded from DB
4	user.name = "Alice Smith"	User instance name changed to 'Alice Smith'	User record still 'Alice'	Instance updated, DB not yet changed
5	user.save	User instance saved with name='Alice Smith'	User record updated to 'Alice Smith'	DB updated
6	user.destroy	User instance marked for deletion	User record deleted	User removed from DB
7	User.find_by(name: "Alice Smith")	No user found	No user record	Returns nil, user deleted

💡 User record deleted, no further operations possible on this user

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
user	nil	User(name='Alice', unsaved)	User(name='Alice', saved)	User(name='Alice', loaded)	User(name='Alice Smith', updated)	User(name='Alice Smith', saved)	User(deleted)	User(deleted)

Key Moments - 3 Insights

Why does the user variable still exist after calling destroy?

The user variable still holds the Ruby object after destroy, but the database record is deleted (see step 6 and 7 in execution_table). The object is disconnected from the DB.

Does changing attributes immediately change the database?

No, changing attributes (step 4) updates the model instance in memory but requires save (step 5) to update DB. (Note: model.update combines attr= and save.)

What happens if we try to find the user after destroy?

The find_by returns nil because the record no longer exists in the database (step 7).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of the user variable after step 3?

A User instance with name='Alice' loaded

B User instance with name='Alice Smith' updated

C User instance marked for deletion

D No user found

💡 Hint

Check the 'Model State' column at step 3 in the execution_table

At which step does the database record change from 'Alice' to 'Alice Smith'?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Database State' column for when the name updates in the execution_table

If we skip calling user.save after step 4, what would happen?

A The user variable would be nil

B The database record would not change

C The database record would update automatically

D The user record would be deleted

💡 Hint

Refer to the explanation in key_moments about changing attributes and save behavior

Concept Snapshot

Rails CRUD through models:
- Create: Model.new + save
- Read: Model.find or find_by
- Update: update (calls save internally) or attr= + save
- Delete: destroy
Changes affect DB immediately after save or destroy
Model instance exists in Ruby memory separately from DB

Full Transcript

This visual execution traces CRUD operations in Rails models. First, a User instance is created in memory with User.new. Then, calling save stores it in the database. Reading uses find_by to load the user from the database. Updating the user changes attributes and saves the changes to the database. Destroy deletes the record from the database but the Ruby object remains until discarded. Trying to find the user after destroy returns nil because the record no longer exists. This shows how model instances and database records interact step-by-step.

Practice

1. Which Rails model method is used to add a new record to the database?

easy

A. create

B. find

C. update

D. destroy

Solution

1. Step 1: Understand CRUD operations

   CRUD means Create, Read, Update, Delete. Each operation has a matching Rails model method.

2. Step 2: Match method to action

   create adds a new record, find reads, update changes, and destroy deletes.

3. Final Answer:

   create -> Option A

4. Quick Check:

   Create = create [OK]

Hint: Create means adding new data, so use create [OK]

Common Mistakes:

• Confusing find with create
• Using update to add new records
• Trying to delete with create

2. Which of the following is the correct syntax to update a user's email in Rails?

easy

A. user.change(email = '[e-mail]')

B. user.update(email: '[e-mail]')

C. user.modify(email: '[e-mail]')

D. user.edit(email => '[e-mail]')

Solution

1. Step 1: Recall Rails update syntax

   The correct method to change attributes is update with a hash of attributes.

2. Step 2: Check syntax correctness

   user.update(email: '[e-mail]') uses symbol keys and colon, which is correct Ruby syntax.

3. Final Answer:

   user.update(email: '[e-mail]') -> Option B

4. Quick Check:

   Update syntax = user.update(hash) [OK]

Hint: Use update with symbol keys and colon for attributes [OK]

Common Mistakes:

• Using assignment (=) inside method arguments
• Using non-existent methods like change or modify
• Wrong hash syntax like email => instead of email:

3. Given the code:

user = User.find(1)
user.destroy
puts User.exists?(1)

What will be printed?

medium

A. An error

B. true

C. nil

D. false

Solution

1. Step 1: Understand what destroy does

   destroy deletes the record from the database permanently.

2. Step 2: Check if record exists after deletion

   User.exists?(1) returns false because the user with ID 1 was deleted.

3. Final Answer:

   false -> Option D

4. Quick Check:

   Destroy removes record, so exists? returns false [OK]

Hint: Destroy deletes record; check existence returns false after [OK]

Common Mistakes:

• Thinking destroy only marks record inactive
• Assuming exists? returns true after deletion
• Confusing destroy with delete (which skips callbacks)

4. Identify the error in this code snippet:

user = User.find_by(id: 10)
user.update(name: 'Alice')

medium

A. No error, code works fine

B. find_by should be find to work

C. find_by returns nil if no record found, so calling update on nil causes error

D. update method does not accept hash arguments

Solution

1. Step 1: Understand find_by behavior

   find_by returns nil if no matching record is found.

2. Step 2: Check method call on nil

   Calling update on nil causes a NoMethodError because nil has no update method.

3. Final Answer:

   find_by returns nil if no record found, so calling update on nil causes error -> Option C

4. Quick Check:

   Nil object has no update method [OK]

Hint: Check if find_by returns nil before calling methods [OK]

Common Mistakes:

• Assuming find_by always returns a record
• Thinking update cannot take hash arguments
• Confusing find and find_by behavior

5. You want to update multiple users' status to 'active' only if their current status is 'pending'. Which Rails code correctly does this in one query?

hard

A. User.where(status: 'pending').update_all(status: 'active')

B. User.update_all(status: 'active').where(status: 'pending')

C. User.find_each { |u| u.update(status: 'active') if u.status == 'pending' }

D. User.all.update(status: 'active') if User.status == 'pending'

Solution

1. Step 1: Filter users with status 'pending'

   User.where(status: 'pending') selects only users with 'pending' status.

2. Step 2: Update all selected users at once

   update_all(status: 'active') updates the status for all filtered users in one database query.

3. Final Answer:

   User.where(status: 'pending').update_all(status: 'active') -> Option A

4. Quick Check:

   Filter then update_all = efficient bulk update [OK]

Hint: Use where to filter, then update_all to bulk update [OK]

Common Mistakes:

• Calling update_all before filtering
• Using find_each which is slower for bulk updates
• Trying to chain where after update_all