Re: Incrementing/decrementing a bogus key (fwd)

[dormando]

I might be okay with this proposal. Any obvious downsides I'm missing?

Recently I added a change so a SET which results in a memory failure will
internally delete an existing value, for similar-but-not-similar data bug
issues.

If no one can think of any downsides and I don't find one while
implementing it, I'll attempt to queue this change for 1.2.7. Patches
welcome too :P

-Dormando

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

[Toru Maesaka]

+1

One concern that came across my mind was accidentally performing
incr/decr on a wrong key (with a valid value for something else) but
this is probably unlikely to happen... Even if it did happen, its the
web developer's fault anyway ;)

Toru

[Toru Maesaka]

Hi!

This is irrelevant to this thread but theres one thing I found weird
with incr/decr while working on making C::M support the binary
protocol. With the ASCII protocol, if an item to incr/decr didn't
exist in the cache beforehand, memcached will return NOT_FOUND.
However, with the binary protocol, if an item didn't exist it will
make an initial one for you.

Personally I like what memcached does for incr/decr with the binary
protocol but wouldn't this become a potential trap for those that are
used to having NOT_FOUND sent back from memcached?

Toru

[Dustin]

On Sep 1, 8:34 pm, "Toru Maesaka" <tmaes...@gmail.com> wrote:
> Hi!
>
> This is irrelevant to this thread but theres one thing I found weird
> with incr/decr while working on making C::M support the binary
> protocol. With the ASCII protocol, if an item to incr/decr didn't
> exist in the cache beforehand, memcached will return NOT_FOUND.
> However, with the binary protocol, if an item didn't exist it will
> make an initial one for you.
>
> Personally I like what memcached does for incr/decr with the binary
> protocol but wouldn't this become a potential trap for those that are
> used to having NOT_FOUND sent back from memcached?

It will actually do, uh, both:

<t>If the expiration value is all one-bits (0xffffffff), the
operation will fail with NOT_FOUND.</t>