INCR, INCRBY do not work correctly on keys with EXPIRE set

[GoogleCodeExporter]

If you follow the steps bellow:
redis-0.093/redis-cli FLUSHDB
OK
redis-0.093/redis-cli SET a 5
OK
redis-0.093/redis-cli EXPIRE a 3600
1
redis-0.093/redis-cli GET a
5
redis-0.093/redis-cli INCR a
1
.. I believe the output should be 6 here... and it's the same problem if 
you combine INCRBY with EXPIRE.

Original issue reported on code.google.com by davor.st...@gmail.com on 29 Apr 2009 at 3:32

[GoogleCodeExporter]

Hello!

this is the right behavior. Write operations against volatile keys (keys with an
expire value associated) remove the key before to perform the operation. To 
check why
please read the manual for the EXPIRE command. It is explained in detail.

Original comment by anti...@gmail.com on 29 Apr 2009 at 3:35

• Changed state: Invalid

[GoogleCodeExporter]

Hi,

I have read the behaviour of EXPIRE before, but as I see it now, I didn't go 
into 
details enough. I just didn't expect that INCRBY would act the way it did...

I wonder if this is the right way to do it... Maybe it would be better to get 
an 
error response instead of setting completly wrong value to the key?

Original comment by davor.st...@gmail.com on 29 Apr 2009 at 4:44

[GoogleCodeExporter]

Hello Davor, unfortunately to return an error does not work in order to have a 
time
independent data model: imagine the following:

{{{
PUSH foo 1
EXPIRE foo 1
... after some time ...
PUSH foo 2
}}}

The only way to ensure that the dataset will be the same both if the second 
push is
performed 1 millisecond after or five seconds after is to consider the key 
already
expired. This can appear an odd feature at first but I think in the long run it 
will
pay to have a very stable replication that is not related to the time factor.

Original comment by anti...@gmail.com on 29 Apr 2009 at 4:56

[GoogleCodeExporter]

Hello Antirez, 

I've solved my problem with INCR & EXPIRE, by not using INCR at all:
{{{
SET a 5
EXPIRE a 60
... 
GET a
5
SET a 5+5
EXPIRE a 60
...
}}}
... it's not a very elegant solution, but it does the trick.

I've been thinking a bit more about this issue...  The INCR is an operation on 
existing key, but it also creates new key with default value 0 and then 
increments 
it in case it doesn't exists. The same thing goes for PUSH, it creates the list 
if 
there's no list... This is convenient, but it also produces unexpected 
behaviour in 
some cases.

The other thing is consistency around the nodes.. 
{{{
Master node:
12:00 PUSH foo 1 
12:01 EXPIRE foo 5
... after some time ...
12:05 PUSH foo 2

Node (~2 sec latency, master timestamp in [])
12:02 [12:00] PUSH foo 1
12:03 [12:01] EXPIRE foo 5 /* dies @ 12:06 */
... after some time ...
12:07 [12:05] PUSH foo 2 /* foo was still live @ 12:05 */
}}}
... in this case you know what to do with the second push - it could fail 
silently.

It's hard to imagine completely time independant model when EXPIRE is one of 
the 
available commands...

Original comment by davor.st...@gmail.com on 2 May 2009 at 8:32