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
