Callbacks are hooks into the life cycle of an Active Record object that allow you to
trigger logic before or after an alteration of the object state. This can
be used to make sure that associated and dependent objects are deleted when
destroy is
called (by overwriting before_destroy)
or to massage attributes before they’re validated (by overwriting before_validation).
As an example of the callbacks initiated, consider the Base#save
call for a new record:

Also, an after_rollbackcallback can be
configured to be triggered whenever a rollback is issued. Check out ActiveRecord::Transactions
for more details about after_commit and after_rollback.

Lastly an after_find and after_initializecallback is triggered for
each object that is found and instantiated by a finder, with
after_initialize being triggered after new objects are
instantiated as well.

That’s a total of twelve callbacks, which gives you immense power to
react and prepare for each state in the Active Record life cycle. The sequence
for calling Base#save for an existing record is similar, except
that each _createcallback is replaced by
the corresponding _updatecallback.

Besides the overwritable callback methods, it’s
also possible to register callbacks through the use of the callback macros. Their
main advantage is that the macros add behavior into a callback queue that is
kept intact down through an inheritance hierarchy.

Now, when Topic#destroy is run only destroy_author is
called. When Reply#destroy is run, both destroy_author
and destroy_readers are called. Contrast this to the following
situation where the before_destroy
method is overridden:

In that case, Reply#destroy would only run
destroy_readers and notdestroy_author. So, use
the callback macros
when you want to ensure that a certain callback is called for
the entire hierarchy, and use the regular overwriteable methods when you
want to leave it up to each descendant to decide whether they want to call
super and trigger the inherited callbacks.

IMPORTANT: In order for inheritance to work for the callback queues, you must
specify the callbacks before specifying the associations. Otherwise, you
might trigger the loading of a child before the parent has registered the
callbacks and they won’t be inherited.

Types of callbacks

There are four types of callbacks accepted by the callback macros: Method
references (symbol), callback objects, inline
methods (using a proc), and inline eval methods (using a string). Method
references and callback objects are the
recommended approaches, inline methods using a proc are sometimes
appropriate (such as for creating mix-ins), and inline eval methods are
deprecated.

The method reference callbacks work by specifying a protected or private
method available in the object, like this:

So you specify the object you want messaged on a given callback. When that callback is triggered,
the object has a method by the name of the callback messaged. You
can make these callbacks more flexible by passing in other initialization
data such as the name of the attribute to work with:

before_validation* returning statements

If the returning value of a before_validationcallback can be
evaluated to false, the process will be aborted and
Base#save will return false. If Base#save! is called it
will raise a ActiveRecord::RecordInvalid
exception. Nothing will be appended to the errors object.

Canceling callbacks

If a before_*callback returns
false, all the later callbacks and the associated action are
cancelled. If an after_*callback returns
false, all the later callbacks are cancelled. Callbacks are
generally run in the order they are defined, with the exception of
callbacks defined as methods on the model, which are called last.

The entire callback
chain of a save,save!, or destroy call runs
within a transaction. That includes after_* hooks. If everything
goes fine a COMMIT is executed once the chain has been completed.

If a before_*callback cancels the
action a ROLLBACK is issued. You can also trigger a ROLLBACK raising an
exception in any of the callbacks, including after_* hooks. Note,
however, that in that case the client needs to be aware of it because an
ordinary save will raise such exception instead of quietly
returning false.

Debugging callbacks

The callback chain is
accessible via the _*_callbacks method on an object. ActiveModel Callbacks support
:before,:after and :around as values for the
kind property. The kind property defines what part of the
chain the callback
runs in.

describeProjectdodescribe'create_milestones'doit'should create an initial milestone'doproject=Project.newproject.milestones.should_receive(:create)project.send(:create_milestones)endenddescribe'notify_owner'doit'should notify its owner'doproject=Project.new(:owner=>mock_model(User))project.owner.should_receive(:project_created!)project.send(:notify_owner)endenddescribe'after_save'doit'should run the proper callbacks'doproject=Project.newproject.should_receive(:create_milestones)project.should_receive(:notify_owner)project.run_callbacks(:after_save)endendend