Close and Go BackBack to Viget

Named Scope Caching

Brian Landau
Brian Landau, Web Developer, August 07, 2008 3

When working on high-traffic Rails sites, it often becomes necessary to find ways to improve performance with caching. One place we’ve found this is most convenient and easy-to-do is by caching an ActiveRecord result set for models that change rarely or not at all. An easy example of this is a Category model.

Often times, you have a categorization hierarchy that will never or rarely change over the life of an application. Ideally you would fetch the results once from the database and never have to again. So how do we go about caching this? First let’s look at our model and create a named_scope for it:

class Category < ActiveRecord::Base
  acts_as_tree
  named_scope :find_top_level, :conditions => 'categories.parent_id IS NULL',
                              :order      => 'categories.name'
end

Next, we need to create create a method that fetches the results for our new scope and caches it in a class variable. It should also only do caching if in production environment (alternatively or additionally, we could use the ActionController.perform_caching config value), as this can cause problems in tests.

def self.top_level
  unless ('production' == RAILS_ENV) && ActionController.perform_caching
    @@top_level_cache = self.find_top_level
  else
    @@top_level_cache ||= self.find_top_level
  end
end

Finally, we need to create a method to invalidate our cache when records are saved or deleted. Since we know this isn’t happening often (if at all), this should rarely be performed but is a good safeguard so we know our cache is current.

after_save :reset_cached_finder
after_destroy :reset_cached_finder

def reset_cached_finder
  @@top_level_cache = nil
end

This is something that we could easily see doing in a number of models for a number of finders. Since this involves a lot of similar code, it would be great if we could create some meta code that would allow us to define these caches with a simple one liner.

Maybe with syntax like cache_scopes :cached_method_name => :scope_name.
For example:

cache_scopes :top_level => :find_top_level

Well here’s the code that does that:

Suggestions for improvement are encouraged, which is easily done with GitHub’s new gist.

Enjoy and have fun caching!

Tom-Eric said on 08/08 at 02:24 AM

Does chaining of named scopes still works when you use caching?

Inflatable Jumpers said on 08/08 at 04:57 AM

Im wondering the same thing as Tom. If there is a potential issue with that would it affect anything else?

Brian Landau said on 08/08 at 09:44 AM

In my quick testing of this it does still work if you chain items after the cache name:

Category.top_level.other_scope

But important to note is this will still make a call to the database, it will not take advantage of the cache. Of course the actual scope, in this case find_top_level is unchanged and so you can still do any chaining with that, which also of course won’t use the cache.

As a final note though if you’re needing to do much chaining, caching in this way may not be best for your particular situation. The idea of the cache is if you need to retrieve the exact same result set over and over again, and it rarely changes you shouldn’t have to hit the database.

Trackback URL: http://www.viget.com/trackback/1222/

Name:

Email:

URL:

Not a robot? Prove it by entering the word below.


Remember my personal information

Notify me of follow-up comments?

A Development Community for Viget Labs and Beyond

Every team member here at Viget Labs strives to be an innovator. We members of the development team are no different - that's why we're constantly engaging in community discussions and exploring the unknown that is the next generation of open-source web applications.

Viget Is Hiring!

Viget has job openings for Ruby Developers, Interns, and Front-End Developers. Learn More »

Recent Comments

I have used several different strategies for achieving this, and have settled on the plugin seed_fu to accomplish this task. Because it uses plain ruby files you have quite a few more options for manipulating your seed data as opposed to using fixtures. I have found that this lets me create seed data that is much less brittle than fixtures can be. You can find seed_fu on...