binary protocol incr/decr proof-of-concept

[Earl Cahill]

While we're here, perhaps I am alone on this, or maybe it is just the perl client, but I think incr and decr should do their thing for new keys.  Currently, in my experience, they return undef for new keys.  I checked in my code and act accordingly.

Thoughts?

Earl

----- Original Message ----
From: Dustin Sallings <dustin at spy.net>
To: Memcached list <memcached at lists.danga.com>
Sent: Wednesday, July 25, 2007 11:36:22 PM
Subject: binary protocol incr/decr proof-of-concept


    I've done an implementation of incr and decr in my test server and  
client (and my real client) as I'd described earlier as a sort of  
proof-of-concept and it seems to work as I was hoping it would.

    It retains much of the properties of the original incr and decr  
implementations, but never treats the number as an ascii string.   
Because of this, I felt that it was important to be able to  
optionally pass a default value into the mutation command.  Since a  
value was needed, it also seemed important to pass the expiration for  
that value.

    Note that this does slightly conflict with the goal of keeping  
commands small and discrete since it may create a new mapping as a  
side-effect.  However, I think it makes things a bit easier.

    The request packet looks like this:

[normal packet stuff]
[32-bit unsigned incr/decr amount]
[32-bit unsigned default value]
[32-bit signed expiration value]
[key]

    The response packet looks like this:

[32-bit unsigned new value]

    If the expiration is less than 0, the default value is ignored and a  
NOT_FOUND status will be returned (as before).

    I had implemented mutation with default in my client by using a sort  
of complicated combinations of mutate and add.  I'm guessing other  
people either do the same thing (or worse, just a mutate or set).

    Note that flags are undefined here.  We talked briefly about having  
flags defined for common encoding mechanisms such as the big-endian  
32-bit unsigned integer used in this response (as would be retrieved  
using a normal ``get'' command).  In the meantime, I've completely  
ignored the problem.

    Comments?

-- 
Dustin Sallings









       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070728/1b3d5f6f/attachment.htm