I'll note that you got exactly the behavior as advertised: the data
did not match the format and was treated as 0, so it's really not an
edge case, per se.
I'd rather see us start to look at the binary protocol's field for
specifying the data type of a value, and specify that incr/decr only
function if the data type is integer.
In either case, adding a new error code, such as your proposed
NOT_NUMBER, makes more sense to me than NOT_FOUND (or more
generically, following my proposal of starting to use the data type
field, WRONG_DATA_TYPE).
Either new error will require client changes, whereas NOT_FOUND will
work with current clients now. It's just that it's an actual corner
case hack, instead of a perceived one, and is certainly a violation of
the principle of least surprise when INCR returns NOT_FOUND, but GET
returns your integer, neatly unserialized for you by your client
library.
Aaron
On Jun 5, 2008, at 12:37 PM, Brad Fitzpatrick wrote:
The memcache protocol for increment says:
The data for the item is treated as decimal representation of a 64-
bit
unsigned integer. If the current data value does not conform to
such a
representation, the commands behave as if the value were 0.
This bit me recently, unknowingly having a Python pickled
(serialized) value in memcache when I thought I had an integer. So
I was actually doing an increment on a serialized integer object,
which memcache treats as a zero, not touching the flags, so when you
fetch it back out, you try to deserialize it, but it's no longer a
serialized object and "boom".
I propose we change this edge case of the protocol and make "incr/
decr" return an error (either NOT_FOUND or NOT_NUMBER) if the value
wasn't a decimal representation of a 64-bit unsigned integer. That
is, the value must effectively match /\s*\d+\s*/. (not proposing we
add a regex library dependency...)
Thoughts, objections?
Brad
