Refactor DalliStore to better support subclassing #417
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:Couple questions that popped up while I was doing this:
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 aDalli::Client
instance viaRails.cache.dalli
? That method won't work with the example pool store above, but I think that's ok.DalliStore#read_multi
callsextract_options!
on its arguments but doesn't assign its return value anywhere unlike other methods such as#fetch_multi
. There's anoptions
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 :)