[PATCH] "incr" supports wraparound

[Clint Webb]

Why would you *want* a wraparound when incrementing?
Quite the opposite for me, I do not want it to wrap around, because then I
would require additional code to check that.  Right now, very simply... if
my increment fails, I reset all the data that is associated with that key,
and start again.

Although, it is possible that treat a '0' returned as a wrap failure in your
scenario, it is easier for me to treat the wrap error the same as if the key
had expired, or the service had been restarted, causing me to replenish the
data that appears to be missing.

On 8/17/07, Evan Miller <emiller at imvu.com> wrote:
>
> Currently Memcached gives an error when incrementing large counters:
>
> set foobar 0 0 10
> 2147483647
> STORED
> incr foobar 1
> 2147483648
> incr foobar 1
> CLIENT_ERROR cannot increment or decrement non-numeric value
>
> I believe this is a bug. Attached is a patch to make counters wrap
> around the 2**32 mark, similar to counters in routers. New behavior:
>
> set foobar 0 0 10
> 4294967294
> STORED
> incr foobar 1
> 4294967295
> incr foobar 1
> 0
>
> A CLIENT_ERROR will continue to be returned if a value above 2**32 is
> incremented, but the "incr" command will never push the value over that
> mark.
>
> A future version of Memcached should probably use a 64-bit counter
> instead, but the 32-bit limit is in line with the existing docs. ("The
> data for the item is treated as decimal representation of a 32-bit
> unsigned integer.")
>
> The patch also adds "const" keywords to arguments of do_add_delta and
> mt_add_delta, to be consistent with the header file.
>
> Documentation and tests have been updated.
>
> Evan Miller
> IMVU, Inc.
>
>


-- 
"Be excellent to each other"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070817/c15ebdcc/attachment.html