I ran into this the other day and it took me a while to figure out
what was going on. This is the paragraph in the Rails book (page 460):
"If a request comes in that invokes one of the actions that the
sweeper is filtering, the sweeper is activated.
If any of the Active Record observer methods fires, the page and
action expiry methods will be called.
If the Active Record observer gets invoked, but the current action is
not selected as a cache sweeper, the expire class in the sweeper are
ignored. Otherwise, expiry takes place"
I had something similiar. I had a method called upload() in my
photo_controller that I renamed to create(), but forgot to change the
cache_sweeper:
cache_sweeper :photo_sweeper, :only => [:upload]
My sweeper looked like this:
class PhotoSweeper < ActionController::Caching::Sweeper
observe Photo
def after_create(record)
return if record.thumbnail?
expire_fragment(%r{photo\/latest})
end
end
This obviously made some caches not expire correctly. However, the
sweeper was still called, because one tells it to observe photos.
However, none of the calls to read_fragment or expire_fragment will
work. You can call them--they just return nil and do nothing.
Unlike the before/after/around_filters, the options :only and :except
don't dictate whether the callbacks (after_create and others) in the
sweeper are called or not. The options dictate whether the cache
expiry functions work while in the sweeper or not.
It seems that the sweepers observe according to their Observable
behavior--they're essentially active record observers, so they will
fire any time the AR class they're observing has a callback. The
sweeper options :only, and :except don't filter out calls, but only
that the cache expiry functions work.
I too found this a bit unintuitive, given how the
before/after/around_filters work. Does anyone else think/feel the
same?