application_record.rb available since rails 5


Bookmark and Share

Those who have been starting with Rails 5, must have noticed the new application_record.rb file present in your model folder. And all new models seems to be inheriting the application_record.rb instead of the ActiveRecord::Base. This is done so that we don’t pollute the ActiveRecord::Base namespace with our own extensions.  Before when we require something, say an extension to the ActiveRecord itself we used to have it included using the following code.

Now the problem with this approach is that when we use rails engines this NewFeature gets added in there as well, and it could end up doing things that we didn’t expect.

With the new application_record.rb, which would be inherited by all the models, we need to include the new module at the ApplicationRecord and it would be available as the new feature of ActiveRecord. Every new engine generated using rails plugin new would also be having their own application_reocord.rb

One more point to note is that we can place application wide hooks in this file. So if you were to do

it would be triggered when a new record is created in any of the models of the rails application.

Read More

after_create vs after_save vs after_commit

after_save, after_create and after_commit are called active record call backs in rails. They get executed when we work on the database, similarly we also have before_* callback and callbacks on destroy as well. In this article I will explain you about the difference between *_save, *_create and *_commit callbacks.

The purpose of each as per rails docs:

after_create
Is called after Base.save on new objects that haven‘t been saved yet (no record exists)

after_save
Is called after Base.save (regardless of whether it‘s a create or update save)

after_commit
Is called after the database transaction is completed.

Now to explain the real difference between the three, we must first explain about database transaction. They are a protective block around a group of sql statements, that are permanent only if all of them succeed in a single atomic statement.

When rails execute a create, the after_save and after_create would be called within the transaction block of the create statement. So they will be executed before executing the sql statement to make permanent changes in the DB. If the query fails, then no change will happen to the DB, but we would have executed the instructions of the after_create and after_save block.

Where as after_commit, is called after the execution of the final/outer transaction block. Thus the changes in the DB would be permanent.

Read More