I gave a short talk on caching with Rails last night at the Seattle.rb meeting. The short version is “the page cache is going to hurt a lot worse then you’d expect,” but anyone who read my previous article on caching should already know that. I did the slides for the talk with S5, which was new to me–I had planned on using Keynote, but it seems to have died in the year and a half since I last had a use for it. S5 worked well enough, although there were some formatting issues that kept popping up as the browser window size changed. By and large it was easy to use, and it’s nice to have a HTML version of the talk that doesn’t look like a nasty afterthought.
About halfway through preparing for the talk, I realized that I really need to add a new action cache option, something like
caches_action_with_params, so we can explicitly say how query strings and other parameters affect the cache. Here’s a bit of sample code:
class ArticlesController < ApplicationController caches_action :index caches_action_with_params :read, :id caches_action_with_params :permalink, :year, :month, :day, :title def index @pages, @articles = paginate( :article, :per_page => config[:limit_article_display], :conditions => 'published != 0', :order_by => "created_at DESC" end def read @article = Article.find( params[:id], :conditions => "published != 0", :include => [:categories]) end def permalink @article = Article.find_by_permalink( params[:year], params[:month], params[:day], params[:title]) end ... end
At least as of Rails 0.13.1, calling
/articles/read?id=10 will create a cache entry for
/articles/read, which is wrong, and then asking for
/articles/read?id=20 will return the cached entry for
id=10. Yes, the user is supposed to use routes for this, but explicit query params still work, and there are times when you really need to use them. Fortunately, this is really only 20 lines of code, so it shouldn’t be too hard to write.