My proposal (and implementation) supports both. If you want it to
automatically create stuff for you, you just specify what the new
value will be. If you don't want it to generate values for you, it
doesn't have to.
Are there semantics you're looking for that aren't covered here?
On Jul 28, 2007, at 0:28, Earl Cahill wrote:
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 <[EMAIL PROTECTED]>
To: Memcached list <[email protected]>
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
Be a better Globetrotter. Get better travel answers from someone
who knows.
Yahoo! Answers - Check it out.
--
Dustin Sallings
