Incrementing/decrementing a bogus key

[Dustin Sallings]

On Jun 5, 2008, at 12:48, Aaron Stone wrote:

> 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.

	I don't think the cost of confusing clients for a bit is higher than  
the cost of corrupting data.

	As you said, it is a corner case.  Few people should ever see it  
unless they're already doing something that would be confusing.

	The binary protocol doesn't solve this problem.  It can guard against  
it if we have more information, but semantics get weird fast.  Right  
now, you can insert a number as a string and increment it with either  
protocol.  Having the binary protocol fail to increment something  
because it wasn't created with incr would be just as surprising.

-- 
Dustin Sallings