Incrementing/decrementing a bogus key

[Brad Fitzpatrick]

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.

- Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20080605/bca1be37/attachment.html