Understanding Active Record Callbacks

Callbacks are methods that get called at certain moments of an object's life cycle. We can use callbacks as a means to manipulate objects further with built-in functionality that Ruby on Rails ships with.

This guide is an overview of Active Record Callbacks and how they can enhance your Ruby on Rails app with seemingly little effort.

To learn even more about Active Record Callbacks I recommend you visit and review the documentation around it.

The available callbacks

Rails ships with a number of callbacks baked in. We can use these methods as a means to perform more logic during, after, before, or around the manipulation of active record objects.

Creating an Object

• before_validation
• after_validation
• before_save
• around_save
• before_create
• around_create
• after_create
• after_save
• after_commit/after_rollback

Updating an Object

• before_validation
• after_validation
• before_save
• around_save
• before_update
• around_update
• after_update
• after_save
• after_commit/after_rollback

Destroying an Object

• before_destroy
• around_destroy
• after_destroy
• after_commit/after_rollback

Registering a callback

A basic example of a callback is as follows. These take place in your models in a given Ruby on Rails application.

Here we register the callback before_validation and reference a Symbol (another method) that will run when a user tries to log in.

class User < ApplicationRecord validates :login, :email, presence: true before_validation :ensure_login_has_value private def ensure_login_has_a_value if login.nil? self.login = email unless email.blank? end end end 

Passing a block

Sometimes your code is short enough to be a one-liner. You can optionally pass a block in the callback instead of referencing another method.

class User < ApplicationRecord validates :login, :email, presence: true before_create do self.name = login.capitalize if name.blank? end end 

Dictate when the callback fires

Extending callbacks with on: allows you to pass one or more lifecycle events dictating when a callback executes. This is really handy!

class User < ApplicationRecord before_validation :normalize_name, on: :create # :on takes an array as well after_validation :set_location, on: [:create, :update] private def normalize_name self.name = name.downcase.titleize end def set_location self.location = LocationService.query(self) end end 

When callbacks get fired

Active Record already gives us a number of methods to transform data via objects. When we run these, callbacks can actually be called.

Some examples

User.destroy_all # The following methods trigger callbacks: # create # create! # destroy # destroy! # destroy_all # save # save! # save(validate: false) # toggle! # touch # update_attribute # update # update! # valid? ## Additionally, the after_find callback is triggered by the following finder methods: User.all # all # first # find # find_by # find_by_* # find_by_*! # find_by_sql # last 

Relational Callbacks

Much like Active Record relations, callbacks can be performed when related objects are changed. A common example of this might be if you destroy a record and have dependent: :destroy enabled. This proceeds to destroy and orphaned data associated with the parent class. What's great is that you can additionally use a callback to perform more operations if necessary.

class User < ApplicationRecord has_many :articles, dependent: :destroy end class Article < ApplicationRecord after_destroy :log_destroy_action def log_destroy_action puts 'Article destroyed' end end >> user = User.first => #<User id: 1> >> user.articles.create! => #<Article id: 1, user_id: 1> >> user.destroy Article destroyed => #<User id: 1> 

Here, a User has many articles. If a user account is deleted, and dependent: :destroy is in place, you can see the after_destroy callback fire.

Conditional callbacks

Often times you might need to conditionally render logic much as you would elsewhere in a Rails app. Luckily, Active Record Callbacks make this quite easy.

You can accomplish conditional callbacks in a few ways. The first is with :if or :unless as a Symbol. This approach makes for quite legible code.

# Using :if and :unless with a Symbol class Order < ApplicationRecord before_save :normalize_card_number, if: :paid_with_card? paid_with_card? # ... end end 

If you have multiple conditions or callbacks you can opt for more logic but the readability gets more complicated.

class Comment < ApplicationRecord after_create :send_email_to_author, if: :author_wants_emails?, unless: Proc.new { |comment| comment.article.ignore_comments? } end 

If there's a bunch of logic to account for it might make sense to extract it to a new Ruby class.

class PictureFileCallbacks def self.after_destroy(picture_file) if File.exist?(picture_file.filepath) File.delete(picture_file.filepath) end end end class PictureFile < ApplicationRecord after_destroy PictureFileCallbacks end 

Hopefully, this guide opened your eyes a bit to how Active Record Callbacks can enhance your toolkit. I find myself using many of these with conditional logic around background jobs, authentication, and more. The possibilities are endless here. I'd aim to use callbacks sparingly where possible. Having too much logic transpiring when modifying objects can get tedious and sometimes slow down your app.

If you enjoyed this guide you might also like:

• Understanding Active Record Associations
• Understanding the Asset Pipeline in Ruby on Rails
• Understanding Active Record Migrations
• Understanding Ruby on Rails ActiveRecord Validations
• Understanding the Ruby on Rails CLI

or more from our Ruby on Rails collection