Incrementing/decrementing a bogus key
brad at danga.com
Thu Jun 5 23:14:56 UTC 2008
On Thu, Jun 5, 2008 at 12:48 PM, Aaron Stone <aaron at serendipity.cx> wrote:
> I'll note that you got exactly the behavior as advertised:
Yes, I know. I cited the protocol doc in my email. And I blame only myself
for even specifying that behavior in the first place: it was out of
laziness just because stroull()'s API kinda sucks.
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.
As Dustin says, this is kinda irrelevant since we don't have a "Create
counter" RPC which initializes a counter. We have to support vivifying a
counter from a string at some point, and will probably forever.
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.
Yeah, pros and cons both ways. Another proposal, just for fun: we could
return NOT_FOUND (pro: no change to clients!) when it's not a number, and
_also_ delete the value. So no "get" surprises later. :-)
But let's do something .... the current behavior is strange for no good
reason. I doubt anybody's relying on it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached