Validate keys when a raw connection is checked out with #with #317
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.
If a raw connection is obtained via #with, this commit causes that connection to in fact be wrapped in a delegator. The delegator will enforce that any keys used with the raw connection belong to the slot that the #with call was pinned to.
This is a replacement for #314 which takes your feedback into account:
I do want to give a bit of insight into why I designed it this way, using
SimpleDelegator
and dynamically detecting which methods to respond to and such. IMO there are two kinds of simplicity we can have here - a simple implementation, which means the code in here is simple, or a simple interface, which means we present an API which does what people expect and is hard to misuse.In my opinion, it's more important for the interface to be simple, than for the implementation to be simple. In this case, if we're proxying an object, a "simple, unsurprising interface" is that it has exactly the same methods which the underlying object has. That means not missing any methods which
RedisClient
has (SimpleDelegator
takes care of that for us), and not adding any additional methods which e.g.RedisClient:Multi
doesn't normally have (i.e. the check fordefine_singleton_method if respond_to?(method)
.It makes the inside of the
PinnedConnectionDelegator
implementation a little more complex, but it makes it less surprising to use for callers, which I think is the most important thing.