- 1.0.0 (0)
- 1.1.6 (8)
- 1.2.6 (0)
- 2.0.3 (1)
- 2.1.0 (8)
- 2.2.1 (0)
- 2.3.8 (0)
- 3.0.0 (0)
- 3.0.9 (-2)
- 3.1.0 (0)
- 3.2.1 (0)
- 3.2.8 (0)
- 3.2.13 (0)
- 4.0.2
- 4.1.8
- 4.2.1
- 4.2.7
- 4.2.9
- 5.0.0.1
- 5.1.7
- 5.2.3
- 6.0.0
- 6.1.3.1
- 6.1.7.7
- 7.0.0
- 7.1.3.2
- 7.1.3.4
- What's this?
Observer classes respond to lifecycle callbacks to implement trigger-like behavior outside the original class. This is a great way to reduce the clutter that normally comes when the model class is burdened with functionality that doesn’t pertain to the core responsibility of the class. Example:
class CommentObserver < ActiveRecord::Observer def after_save(comment) Notifications.deliver_comment("admin@do.com", "New comment was posted", comment) end end
This Observer sends an email when a Comment#save is finished.
class ContactObserver < ActiveRecord::Observer def after_create(contact) contact.logger.info('New contact added!') end def after_destroy(contact) contact.logger.warn("Contact with an id of #{contact.id} was destroyed!") end end
This Observer uses logger to log when specific callbacks are triggered.
Observing a class that can’t be inferred
Observers will by default be mapped to the class with which they share a name. So CommentObserver will be tied to observing Comment, ProductManagerObserver to ProductManager, and so on. If you want to name your observer differently than the class you’re interested in observing, you can use the Observer.observe class method:
class AuditObserver < ActiveRecord::Observer observe Account def after_update(account) AuditTrail.new(account, "UPDATED") end end
If the audit observer needs to watch more than one kind of object, this can be specified with multiple arguments:
class AuditObserver < ActiveRecord::Observer observe Account, Balance def after_update(record) AuditTrail.new(record, "UPDATED") end end
The AuditObserver will now act on both updates to Account and Balance by treating them both as records.
Available callback methods
The observer can implement callback methods for each of the methods described in the Callbacks module.
Storing Observers in Rails
If you’re using Active Record within Rails, observer classes are usually stored in app/models with the naming convention of app/models/audit_observer.rb.
Configuration
In order to activate an observer, list it in the config.active_record.observers configuration setting in your config/environment.rb file.
config.active_record.observers = :comment_observer, :signup_observer
Observers will not be invoked unless you define these in your application configuration.
Generate an observer
Generating an observer from the command line follows the usual pattern:
script/generate observer audit
This will create a model called:
app/models/audit_observer.rb
Using observers with script/runner
If yoo need to use some observers but you don’t want then in the initialization you can do this in your script:
ActiveRecord::Base.observers = [ProductObserver, UserObserver] ActiveRecord::Base.instantiate_observers
Your observers should work during the execution of the script.
(For the sweepers the solution is a bit different, look at my Caching module note for the complete solution).