after_save
- 1.0.0 (0)
- 1.1.6 (10)
- 1.2.6 (0)
- 2.0.3 (1)
- 2.1.0 (0)
- 2.2.1 (18)
- 2.3.8 (0)
- 3.0.0
- 3.0.9
- 3.1.0
- 3.2.1
- 3.2.8
- 3.2.13
- 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?
after_save()
public
Is called after Base.save (regardless of whether it’s a create or update save). Note that this callback is still wrapped in the transaction around save. For example, if you invoke an external indexer at this point it won’t see the changes in the database.
class Contact < ActiveRecord::Base after_save { logger.info( 'New contact saved!' ) } end
Return True
As is the case with the before_validation and before_save callbacks, returning false will break the callback chain. For example, the expire_cache_id method will not run if Rails.cache.expire returns false (as it will if the key is not cached with memcache).
Returning False Example (Bad)
after_save :expire_cache_by_name after_save :expire_cache_by_id def expire_cache_by_name Rails.cache.expire("my_object:name:#{self.name}") end def expire_cache_by_id Rails.cache.expire("my_object:#{self.id}") end
Returning True Example (Good)
def expire_cache_by_name Rails.cache.expire("my_object:name:#{self.name}") return true end def expire_cache_by_id Rails.cache.expire("my_object:#{self.id}") return true end
gives a parameter
As a note, you can use it like this:
after_save {|instance|
}
it will pass in the instance being saved.
Tested w/ Rails 3 and returning true/false ignored
Per http://ar.rubyonrails.org/classes/ActiveRecord/Callbacks.html “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.” [and presumably associated action is not canceled]
So, the callback chain will be broken, but the save will still happen.
Also ran into this: http://innergytech.wordpress.com/2010/03/08/dont-put-validations-in-after_save/