Association callbacks in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a child record is destroyed with dependent: :destroy?

Consider a Rails model Author has_many books with dependent: :destroy. What happens when an Author is destroyed?

Ruby on Rails

class Author < ApplicationRecord
  has_many :books, dependent: :destroy
end

class Book < ApplicationRecord
  belongs_to :author
  before_destroy :log_destroy

  def log_destroy
    puts "Destroying book #{id}"
  end
end

# In console:
author = Author.find(1)
author.destroy

A The author is destroyed first, then all associated books are destroyed without running callbacks.

B The author is destroyed and associated books remain in the database with author_id set to NULL.

C All associated books are destroyed and their before_destroy callbacks run before the author is destroyed.

D Destroying the author raises an error because dependent: :destroy is not supported.

💡 Hint

Think about the order of callbacks and what dependent: :destroy means.

With dependent: :destroy, Rails destroys all associated records by calling their destroy method, which triggers callbacks like before_destroy. This happens before the parent record is destroyed.

❓ lifecycle

intermediate

When is the after_add callback triggered in a has_many association?

Given a has_many :comments, after_add: :notify_addition association, when does the notify_addition method get called?

Ruby on Rails

class Post < ApplicationRecord
  has_many :comments, after_add: :notify_addition

  def notify_addition(comment)
    puts "Added comment #{comment.id}"
  end
end

post = Post.find(1)
comment = Comment.new(content: 'Nice post!')
post.comments << comment

A Only after the comment is saved to the database and associated with the post.

B Immediately after a comment is added to the association collection in memory, before saving to the database.

C When the post itself is saved, regardless of changes to comments.

D Only when the comment is destroyed from the association.

💡 Hint

Consider when the callback triggers relative to adding objects to the association.

The after_add callback runs immediately after an object is added to the association collection in memory, even before saving it to the database.

📝 Syntax

advanced

Which option correctly defines a before_remove callback in a has_many association?

Choose the correct syntax to define a before_remove callback on a has_many :tags association that calls log_removal.

Ruby on Rails

class Article < ApplicationRecord
  has_many :tags, ???

  def log_removal(tag)
    puts "Removing tag #{tag.id}"
  end
end

A before_remove: :log_removal

B before_remove => :log_removal

C before_remove :log_removal

D before_remove = :log_removal

💡 Hint

Look for the correct Ruby hash syntax for options in associations.

The correct syntax uses a symbol key and symbol value with a colon: before_remove: :log_removal.

🔧 Debug

advanced

Why does the after_add callback not trigger when using update to change association?

Given this code:

post.comments << comment
post.update(comments: post.comments + [new_comment])

The after_add callback on comments does not run for new_comment. Why?

A Because <code>new_comment</code> is not saved before adding to the association.

B Because <code>after_add</code> only triggers on <code>delete</code> operations, not additions.

C Because <code>after_add</code> only triggers on <code>build</code> method calls.

D Because <code>update</code> replaces the association without triggering callbacks like <code>after_add</code>.

💡 Hint

Think about how callbacks are triggered when modifying associations directly vs. via update.

Using update with an array replaces the association in bulk and does not trigger after_add callbacks, which only run when adding objects directly to the association collection.

🧠 Conceptual

expert

What is the effect of using :before_add and :after_remove callbacks together on a has_many association?

In a has_many :items, before_add: :check_limit, after_remove: :log_removal association, what is the combined effect of these callbacks?

A Before adding an item, <code>check_limit</code> runs to possibly prevent addition; after removing an item, <code>log_removal</code> runs to record the removal.

B Both callbacks run only after the parent object is saved, not during association changes.

C The callbacks run only if the associated items are destroyed, not when added or removed from the collection.

D The callbacks run in reverse order: <code>log_removal</code> before removal and <code>check_limit</code> after addition.

💡 Hint

Consider the timing and purpose of before_add and after_remove callbacks.

before_add runs before an object is added to the association, allowing checks or prevention. after_remove runs after an object is removed, useful for logging or cleanup.

Practice

1. What is the purpose of after_add and after_remove callbacks in Rails associations?

easy

A. To define database indexes on associations

B. To validate the presence of associated records

C. To preload associated records for performance

D. To run code automatically when related records are added or removed

Solution

1. Step 1: Understand association callbacks

   Rails provides after_add and after_remove callbacks to trigger code when associated records change.

2. Step 2: Identify their purpose

   These callbacks run automatically when you add or remove related records, helping keep data in sync.

3. Final Answer:

   To run code automatically when related records are added or removed -> Option D

4. Quick Check:

   Association callbacks = automatic code on add/remove [OK]

Hint: Callbacks run code on add/remove related records [OK]

Common Mistakes:

• Confusing callbacks with validations
• Thinking callbacks preload data
• Assuming callbacks define indexes

2. Which is the correct syntax to add an after_add callback to a has_many association named comments in a Rails model?

easy

A. has_many :comments, after_add: :notify_comment_added

B. has_many :comments, after_add => :notify_comment_added

C. has_many :comments do after_add :notify_comment_added end

D. has_many :comments, callback_after_add: :notify_comment_added

Solution

1. Step 1: Recall correct hash syntax for options

   Rails uses symbol keys with colon and value pairs like after_add: :method_name.

2. Step 2: Match syntax to association

   The correct syntax is has_many :comments, after_add: :notify_comment_added.

3. Final Answer:

   has_many :comments, after_add: :notify_comment_added -> Option A

4. Quick Check:

   Use colon syntax for options in associations [OK]

Hint: Use colon syntax for options in associations [OK]

Common Mistakes:

• Using hash rocket => instead of colon :
• Trying to define callback inside block
• Using wrong option name like callback_after_add

3. Given the following code, what will be printed when a new comment is added to a Post?

class Post < ApplicationRecord
  has_many :comments, after_add: :log_comment_added

  def log_comment_added(comment)
    puts "Comment added: #{comment.body}"
  end
end

post = Post.new
post.comments << Comment.new(body: 'Nice post!')

medium

A. No output

B. Comment added: Nice post!

C. Error: undefined method log_comment_added

D. Comment added:

Solution

1. Step 1: Understand after_add callback behavior

   The after_add callback calls log_comment_added with the new comment when added.

2. Step 2: Check the method output

   The method prints "Comment added: " plus the comment's body, which is "Nice post!".

3. Final Answer:

   Comment added: Nice post! -> Option B

4. Quick Check:

   after_add calls method with new record [OK]

Hint: after_add calls method with added record [OK]

Common Mistakes:

• Expecting no output
• Thinking callback is not triggered on << operator
• Assuming method is missing error

4. Identify the error in this Rails model code using after_remove callback:

class User < ApplicationRecord
  has_many :posts, after_remove: :notify_post_removed

  def notify_post_removed
    puts 'Post removed'
  end
end

medium

A. The callback method must accept the removed record as an argument

B. The callback name should be after_remove_post

C. The after_remove option is not valid for has_many

D. The method should be private

Solution

1. Step 1: Check callback method signature

   Callbacks like after_remove receive the removed record as an argument.

2. Step 2: Compare method definition

   The method notify_post_removed has no parameters, so it will cause an error.

3. Final Answer:

   The callback method must accept the removed record as an argument -> Option A

4. Quick Check:

   Callback methods need removed record argument [OK]

Hint: Callback methods must accept the changed record argument [OK]

Common Mistakes:

• Defining callback method without parameters
• Using invalid callback option name
• Thinking method visibility causes error

5. You want to track when tags are added or removed from an Article model using has_many :tags. You want to update a counter on Article each time tags change. Which is the best way to implement this using association callbacks?

hard

A. Use before_save callback on Article to count tags

B. Override the tags= setter method to update the counter

C. Use after_add and after_remove callbacks on has_many :tags to update the counter method

D. Manually call a method to update the counter after changing tags

Solution

1. Step 1: Understand the goal

   You want to update a counter automatically when tags are added or removed.

2. Step 2: Choose appropriate callback

   after_add and after_remove on has_many :tags run code exactly when tags change.

3. Step 3: Compare other options

   Overriding setter or using before_save is less direct and can miss changes; manual calls are error-prone.

4. Final Answer:

   Use after_add and after_remove callbacks on has_many :tags to update the counter method -> Option C

5. Quick Check:

   Use association callbacks for automatic related record updates [OK]

Hint: Use after_add and after_remove for automatic updates [OK]

Common Mistakes:

• Overriding setter unnecessarily
• Using before_save which may miss association changes
• Forgetting to automate updates