This is what I have learned from trying to expire fragment cache from background scripts in Ruby om Rails. It simply is not possible. If a controller is not instantiated when you hit the expire_fragment method
(or any other cache sweeper method) you get a nil reply.

I understand why this decision has been made: Fragments are in views. Only the controller should deal with views. The controller is instantiated when it is requested by the web-server. Otherwise you break the MVC paradigm. Except that this mental model does not take into account the fact that
every web-application (except the simplest ones) have stuff going on in the background. Long calculations are made by script so the user doesn’t have to wait while they are being finished. Stuff is done at a given time of day, like expiring old subscriptions. This is why we have BackgroundDRB and BJ. Background jobs need access to the fragment cache. If anyone who is really into rails could find a way to let background jobs do fragment cache things, I’d be very grateful.

For now, I have to periodically expire or reset all fragments because I know that background jobs periodically change the data used to generate them. Most inelegant and inefficient.


def cached_books
get_cache(:author_books) do
Book.find_by_author_id(self.id)
end
end


This method caches all books belonging to an author. Cache fu does not cache belongs_to or has_(one|many) relationships, and that’s why we have this method. But this also means that if we add a book to an author, we must also expire the author records cache. This can all be done with cache_fu. The problem is that these relationships might get quite complicated and it would be nice to be able to write some specs that test that everything behaves as intended.

Chris Wanstrath, the author of cache_fu, suggests using mocha to stub everything about, but didn’t want to emulate the caching behavior and then test if the behavior is right. That is fine if you test the cache_fu plugin, but not fine if you need to test if your application uses the cache_fu plugin correctly. What I wanted was to turn on caching while running my specs and then query the cache to see if things are actually cached properly.

This first this I tried was turning on caching in the “test” environment. Turns out that it is not a good idea, as a lot of specs go into some kind of recursive error when you do that. Caching should be off by default in test. I needed a way to turn on the cache functions in a given spec.

Long story short: for unit testing you add the following function to your model:


class << self
def reenable_cache_for_test
class << self
alias_method :fetch_cache, :fetch_cache_without_disabled
alias_method :set_cache, :set_cache_without_disabled
alias_method :expire_cache, :expire_cache_without_disabled
end
end
end


You call this method in your spec like this:


it "should cache author" do
Author.reenable_cache_for_test

CACHE.flush_all
CACHE.get('Author:1').should == nil
author = Author.get_cache(1)
author.should != nil
CACHE.get('Author:1').should == author

CACHE.get('Author:1:books').should == nil
books = user.cached_books
CACHE.get('Author:1:books).should == books
end


Fragment caching is a bit different, in you controller spec you do this:


it "fragment should be cached on get" do
ActionController::Base.perform_caching = true
ActsAsCached.config.clear
config = YAML.load_file( File.dirname(__FILE__) + '/../../vendor/plugins/cache_fu/defaults/memcached.yml.default')
config['test'] = config['development'].merge('benchmarking' => false, 'disabled' => false)
ActsAsCached.config = config
ActsAsCached::FragmentCache.setup!

CACHE.flush_all

… and then do your cache checking.


%span{:id => "name", :class => "in_place_editor_field"}= @user.name
= in_place_editor "name", {:url => '/user/edit/' + @user.id.to_s, :rows => 1, :size => 32 }


So basically I hard coded the route so it would fall back on standard routing. Yes I know that:

• This is ugly as sin
• I’m supposed to do a PUT request to a function named update, not a post request to a function named edit.

But it solved the problem.

• If you want to migrate a specific database, you can do it by setting RAILS_ENV on the command line. Like this:
  rake db:migrate RAILS_ENV=production
• If you want to see all the rake tasks in your application with a description of what they do, execute:
  rake -D