First, if this is known to people, great, if not I hope it helps others, as I wasn't able to find this in all the Googling I did. Furthermore, since this turned out to be such a simple solution, I'm curious if there are holes...
I wanted to setup more significant caching for some heavy use types of pages on DealBase. Various things have made this challenging to date, but the last thing I ran into was dealing with the fact that query parameters change page results (duh), but that of course Rails' page and action caching ignore query parameters. There isn't an easy (or?) way to get around the page caching part unless you start mucking with Nginx rules as well I think. But, action caching has a solution. I had done a ton of Googling on this, and I knew about adjusting the cache_path, as well as some other bits, but we have cases where there are a lot of parameters. Plus, I didn't want to worry about what happens if I add a new search/filter type of parameter later on, and having to remember to add that to the list of things the cache_path differed on.
As it turns out, you can simply do regular action caching, with full query parameter support, very easily with:
caches_action :my_action, :cache_path => Proc.new { |controller| controller.params }
That will do the regular style of action caching, but stick all your query parameters on (in alphabetical order so you don't have to worry about different query parameter order not retrieving the same cache results). Now, it's quite likely that you'll want something a bit fancier. For example, here's something closer to what I use in reality:
caches_action :action_one, :action_two,
:cache_path => Proc.new { |c| c.params.delete_if { |k,v| k.starts_with?('utm_') } },
:expires_in => 4.hours,
:unless => Proc.new { |c| c.request.xml_http_request? || c.send(:current_user).try(:admin?) }
This just adds in some conditions, as well as removes some query parameters that I don't want to differentiate the cache on ("utm" keywords for Google Analytics, etc.). In this particular case we're not caching the page at all if it's an AJAX request or for our admins.
Finally, one comment is that you do need to be careful with things like pagination. In many cases, page 1 is going to get viewed a ton, and maybe page 2, or page 17 for that matter are rarely viewed. You could have a case where you make updates to the content that then makes a change such that the different pages are out of sync and thus you have duplicate items on pages or missing items. You could skip using expires_in, and use cache sweepers if that works for you, but factor in how often updates are happening and whether that might nullify the advantage of caching (i.e. if you do frequent updates, it'd expire your cache a lot and maybe too often to benefit from it if you have high rate of updates).
What say you? Anyone else doing this, any other issues?
