v1.0.0 - Show latest stable - 5 notes

Action caching is similar to page caching by the fact that the entire output of the response is cached, but unlike page caching, every request still goes through the Action Pack. The key benefit of this is that filters are run before the cache is served, which allows for authentication and other restrictions on whether someone is allowed to see the cache. Example: 

  class ListsController < ApplicationController
    before_filter :authenticate, :except => :public
    caches_page   :public
    caches_action :show, :feed
  end

In this example, the public action doesn’t require authentication, so it’s possible to use the faster page caching method. But both the show and feed action are to be shielded behind the authenticate filter, so we need to implement those as action caches.

Action caching internally uses the fragment caching and an around filter to do the job. The fragment cache is named according to both the current host and the path. So a page that is accessed at http://david.somewhere.com/lists/show/1 will result in a fragment named "david.somewhere.com/lists/show/1". This allows the cacher to differentiate between "david.somewhere.com/lists/" and "jamis.somewhere.com/lists/" — which is a helpful way of assisting the subdomain-as-account-key pattern.

Show files where this module is defined (1 file)
Register or log in to add new notes.
June 20, 2008
10 thanks

Set cache time-to-live

You can specify time-to-live for the cached item in seconds with :expires_in option.

class ListsController < ApplicationController
  caches_action :index, :expires_in => 1.hour
end
June 25, 2008
5 thanks

:expires_in not in Rails 2.1

AFAIK this is from a patch to Rails 2.1, which hasn’t been accepted yet.

http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/416-caches_actions-accepts-cache_store-options-such-as-expires_in

Also, I think it needs to be supported by the cache_store you’re using.

September 19, 2008 - (v2.1.0)
3 thanks

:expires_in option

If you need :expires_in functionality in Rails 2.1, you can use this plugin:

http://github.com/nickpad/rails-caches-action-patch/tree/master

January 30, 2010
3 thanks

Paying attention to query parameters

Standard action caching ignores query parameters, which means you’d get the same results for a URL with and without query parameters if it was action cached. You can make it pay attention to them by using a custom cache path like so:

caches_action :my_action, :cache_path => Proc.new { |c| c.params }

Or, maybe you want some of the query parameters, but not all to factor into different versions of that action’s cache:

:cache_path => Proc.new { |c| c.params.delete_if { |k,v| k.starts_with?('utm_') } }

Beware of things like pagination if you use expires_in to expire the cache, as pages could get out of sync.

December 6, 2008
0 thanks

:cache_path strangeness

I’ve noticed that using an example like this one shown in the docs has some issues with URI escaping:

caches_action :feed, :cache_path => Proc.new { |controller|
     controller.params[:user_id] ?
       controller.send(:user_list_url, controller.params[:user_id], controller.params[:id]) :
       controller.send(:list_url, controller.params[:id]) }
 end

When I do this, the :myroute_url methods return URLs with escaped parameters, as one would expect, but for some reason Rails unescapes these strings by the time it uses them to store the cache blob. This is messing up my cache expiration routines, because they keep track of the escaped versions of the urls that are returned by the routing methods, not the unescaped versions. It would be easier if Rails didn’t do any magic to the string and simply used exactly what you pass to cache_path.