mperham/dalli — pull request #417 by jcxplorer (2013-12-28 09:07:14+00:00)
Title: Refactor DalliStore to better support subclassing

As promised, here's a pull request that makes DalliStore a little easier to subclass, for example, to add support for a connection pool.

I took an approach that adds a `#with_connection` method through which the Dalli client is always accessed. It seemed like the best way to support a connection pool in a subclass, which can be done using the *connection_pool* gem:

``` ruby
module ActiveSupport
module Cache
class DalliPoolStore < DalliStore

def initialize(pool, options={})
@pool = pool
@options = options
extend Strategy::LocalCache
end

def with_connection(&block)
@pool.with(&block)
end

end
end
end
```

``` ruby
dalli_pool = ConnectionPool.new(size: 25, timeout: 5) { Dalli::Client.new("localhost:11211", threadsafe: false) }
config.cache_store = :dalli_pool_store, dalli_pool
```

Couple questions that popped up while I was doing this:

1. `DalliStore#dalli` is not used anywhere and the tests don't seem to mind if it's not defined. Was it used internally at some point or is it just to provide access to a `Dalli::Client` instance via `Rails.cache.dalli`? That method won't work with the example pool store above, but I think that's ok.

2. `DalliStore#read_multi` calls `extract_options!` on its arguments but doesn't assign its return value anywhere unlike other methods such as `#fetch_multi`. There's an `options` variable being used later which ends up being the options passed when the DalliStore is created. Is this intentional or a bug? I'm not familiar enough with the code to be able to tell :)