Active Record Callbacks

Use Cases of Callbacks / Observers

Force a Rollback (prevent the model from being saved) under certain circumstances Track Activities, Log Changes, Send Notifications Ensure the existance of associated objects Inform associated models about changes Save Information about the circumstances the model was saved / created (e.g. date / time) Trigger a state change Process raw data into more usabale data (e.g.

Overview
Creating an Object

before_validation After_validation before_save around_save before_create around_create after_create after_save

Updating an Object before_validation after_validation before_save around_save before_update around_update after_update after_save

Destroying an Object before_destroy around_destroy after_destroy

Initializing an Object after_initialize after_find

Callback Chain
Stolen from the rails guide:

Callback Chain
Stolen from the rails guide:

or: before_update or: after_update

Callback Chain
Stolen from the rails guide:

or: before_update or: after_update The only two callbacks called after the transaction

or: after_rollback

Callback Chain
Stolen from the rails guide: Additional to the callbacks in the save / destroy workflow: - after_find - after_initialize => after a object was found, and initiated by a finder, while after_initialize is triggered for new_records as well. or: before_update or: after_update The only two callbacks called after the transaction

or: after_rollback

Transactions

Are a database feature Wrapped by ActiveRecord::Transactions

Typical Example for Transaction stolen from Railsguides:

Read more about Transactions and the ARSupport for different Databases here: http://api.rubyonrails.org/classes/ActiveRecord/Transa

Rollback Transactions

All Exceptions thrown within an transactions are caught, and trigger a rollback, before they are re-raised by the transaction block (catch them) Exception: raising ActiveRecord::Rollback triggers a rollback, but is not re-raised Catching Exceptions inside the transaction, means it doesn't trigger a callback. Which might cause unwanted behaviour / trouble (e.g. AR::StatementInvalid)

Callbacks and Transactions

Still true: All after-/before validate-/save-/update-/create callbacks are run inside a transaction Ways to cancel the transactions:

Raise an exception ( be ready to catch it) Return false ( even if it is unwanted, be sure to check the return value of the last method call In your) Try to save or create an invalid record.

Being in a transaction means all changes I apply to any other active record object, are

Custom Callbacks

Note: If you include ActiveSupport::Callbacks this works with any kind of ruby class

Observer

Allow to use the same callbacks as available in the model itself Main purpose is to free models from callbacks that don't affect the model itself, e.g. sending a notification email. Are also wrapped inside the transaction.

Oberserver Examples

Callback Classes

Similar to observers you can also pass a class (or instance of a class) to a callback

More

If changing (associated) models in callbacks, never call .save or .create use build instead. Associated objects will be saved together with the original model. Callbacks can take conditions (:if, and :unless), taking a method (symbol), proc or string (not recommended) Never call .valid? Inside a after_validation callback stack level too deep