Incrementing/decrementing a bogus key

[Aaron Stone]

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
>