Yeah, definitely memcache tells you in both protocols whether the key was
found or not (never set, expired, whatever). So I'd say storing nil goes
well with memcache semantics.
The basic premise that we should follow memcache semantics is sound
regardless of the actual semantics :).
So in my view we have impedances in two places: AFAIK dalli returns nil in
either case, and the interface of AS stores documents the same behavior for
#read.
If the client gave you a way to distinguish whether the key is unknown or
the cached value nil, you could implement a smarter #fetch with block in
the memcache store, though #read would not be able to tell you unless we
modify the contract.
Given this situation my thoughts are:
1) I'd love to get rid of Entry due to the impact.
2) But, we should be able to cache nil values in #fetch.
Unless AS changes the memcache client with another one that supports
reporting unknown keys, I see no way to get rid of Entry. And if we keep
Entry, the enhancements done by Brian are an important improvement over the
current implementation.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
