- 1.0.0 (0)
- 1.1.6 (0)
- 1.2.6 (4)
- 2.0.3 (8)
- 2.1.0 (2)
- 2.2.1 (3)
- 2.3.8 (0)
- 3.0.0 (1)
- 3.0.9 (5)
- 3.1.0 (-1)
- 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?
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 Action Pack. The key benefit of this is that filters run before the cache is served, which allows for authentication and other restrictions on whether someone is allowed to execute such action. Example:
class ListsController < ApplicationController before_filter :authenticate, :except => :public caches_page :public caches_action :index, :show end
In this example, the public action doesn’t require authentication so it’s possible to use the faster page caching. On the other hand index and show require authentication. They can still be cached, but we need action caching for them.
Action caching uses fragment caching internally and an around filter to do the job. The fragment cache is named according to the host and path of the request. A page that is accessed at http://david.example.com/lists/show/1 will result in a fragment named david.example.com/lists/show/1. This allows the cacher to differentiate between david.example.com/lists/ and jamis.example.com/lists/ – which is a helpful way of assisting the subdomain-as-account-key pattern.
Different representations of the same resource, e.g. http://david.example.com/lists and http://david.example.com/lists.xml are treated like separate requests and so are cached separately. Keep in mind when expiring an action cache that :action => 'lists' is not the same as :action => 'list', :format => :xml.
You can modify the default action cache path by passing a :cache_path option. This will be passed directly to ActionCachePath.path_for. This is handy for actions with multiple possible routes that should be cached differently. If a block is given, it is called with the current controller instance.
And you can also use :if (or :unless) to pass a proc that specifies when the action should be cached.
Finally, if you are using memcached, you can also pass :expires_in.
The following example depicts some of the points made above:
class ListsController < ApplicationController before_filter :authenticate, :except => :public caches_page :public caches_action :index, :if => proc do !request.format.json? # cache if is not a JSON request end caches_action :show, :cache_path => { :project => 1 }, :expires_in => 1.hour caches_action :feed, :cache_path => proc do if params[:user_id] user_list_url(params[:user_id, params[:id]) else list_url(params[:id]) end end end
If you pass :layout => false, it will only cache your action content. That’s useful when your layout has dynamic information.
Warning: If the format of the request is determined by the Accept HTTP header the Content-Type of the cached response could be wrong because no information about the MIME type is stored in the cache key. So, if you first ask for MIME type M in the Accept header, a cache entry is created, and then perform a second request to the same resource asking for a different MIME type, you’d get the content cached for M.
The :format parameter is taken into account though. The safest way to cache by MIME type is to pass the format in the route.
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
:expires_in not in Rails 2.1
AFAIK this is from a patch to Rails 2.1, which hasn’t been accepted yet.
Also, I think it needs to be supported by the cache_store you’re using.
: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
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.
: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.