[Feature Request] SetNxEx (Set if Not Exists + Expire at the same time)

[GoogleCodeExporter]

Hello,

I was wondering if it could be possible to add a new command SetNXEx as 
described in my summary. Which allows client to set a key with an expiry (like 
SetEx) only if the key does not exist ?
I know that in older versions it wasn't possible and even try to perform a 
SetNx command on a key with expiry could failed (before 2.2.x).

I'm not completly aware of all problems that would result, but when I had a 
look to the 2.2.0 code, I saw that SetNxCommand is calling the
setGenericCommand with nx = 1 and expire = NULL.
Besides, SetExCommand is calling the setGenericCommand with nx = 0 and expire 
!= NULL.

As a neophyte of Redis code ... I'm just asking if it is possible to merge them 
together to create the new SetNxExCommand ?

Regards !

Original issue reported on code.google.com by Baptiste...@gmail.com on 27 Jul 2011 at 9:59

[GoogleCodeExporter]

Why not use a "setnx" command, check the result, and then
optionally call "expire" instead?

If you are concerned by the extra roundtrip, it will be
solved by Lua scripting support. I doubt that new commands
that could be implemented as a script will be added at
this stage.

Regards,
Didier.

Original comment by didier...@gmail.com on 27 Jul 2011 at 6:04

[GoogleCodeExporter]

As you said, there is an extra roundtrip which could be a significant overhead 
but also make the operation non-atomic.

Lua scripting support could be a solution, but to my mind, the "SetNxEx" is 
useful enough to be parts of Redis command list if possible. Scripting is good, 
but should be used for exceptional/custom use only; especially if the 
implementation of the method just need to call an existing function with 
differents parameters.

Regards,
Baptiste.

Original comment by Baptiste...@gmail.com on 27 Jul 2011 at 7:37

[GoogleCodeExporter]

I would find this feature very useful too. The beauty of it is that is a very 
elegant way to handle locks. You just need to to execute setnxex and check the 
return value to know if you acquired the lock. The need to use 2 calls (setnx 
and expire) could cause the client to die in the middle of those causing a 
deadlock. 

Original comment by jordi...@gmail.com on 10 Apr 2012 at 11:42

[GoogleCodeExporter]

@jordi: In fact, as Didier told me, the new LUA scripting feature (2.6.0) 
provides a way to avoid this case.

@All: But!! The LUA solution is a client solution, which needs to implement the 
script ... compute the SHA1 in memory and to increase performance keep it in 
memory.

The Redis philosophy is to keep the API simple ... to my mind, forcing all 
client developers to write their own version of the SETNXEX implementation is 
not what common people call "a simple API".

I already tried -successfuly- to modify Redis sources to add the SETNXEX and 
PSETNXEX commands to the API, it's only 10 lines of code per commands 
-including the redis-cli help-.
Since it uses the existing "atomic" implementation for SETEX and SETNX, its 
pretty simple to test it and ensure that it works. My only regrets is that I'll 
have to maintains my fix/hack in the Redis code until Antirez or someone e

It could be very nice if this feature (+ its precision version) could be 
shipped within the 2.6.0 incoming version.

P.S.: The SETX and PSETX methods could be something good too, but 4 new methods 
could be too much to ask, and I think SETNXEX and SET

Original comment by Baptiste...@gmail.com on 10 Apr 2012 at 2:37

[GoogleCodeExporter]

Related issue: https://github.com/antirez/redis/issues/428

Original comment by alexey.p...@gmail.com on 15 Oct 2012 at 10:16