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 On Tue, Sep 2, 2008 at 11:18 AM, Toru Maesaka <[EMAIL PROTECTED]> wrote: > +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 > > On Tue, Sep 2, 2008 at 7:39 AM, dormando <[EMAIL PROTECTED]> wrote: >> >> 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 >>> >> >
