incr and expire

34 views
Skip to first unread message

Steve Farrell

unread,
Dec 6, 2009, 2:01:33 AM12/6/09
to redi...@googlegroups.com
i have a script like:

puts Service.redis.incr "test"
Service.redis.expire "test", 1.hour.to_i
puts Service.redis.incr "test"

and when i run it i get

1
1

as output, while i expected

1
2

what's up?  am i missing something?

Matt Todd

unread,
Dec 6, 2009, 4:18:47 AM12/6/09
to redi...@googlegroups.com
I was able to reproduce this behavior, but had to double check why this was expected.


"There is so a simple rule, write operations against volatile keys will destroy the key before to perform the operation."

Essentially, volatile keys are considered well enough deleted and should be removed before performing any write request.

Matt



--

You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.



--
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org

Scout - Web Monitoring and Reporting Software
www.scoutapp.com

Salvatore Sanfilippo

unread,
Dec 6, 2009, 5:03:21 AM12/6/09
to redi...@googlegroups.com
On Sun, Dec 6, 2009 at 10:18 AM, Matt Todd <chio...@gmail.com> wrote:

> Essentially, volatile keys are considered well enough deleted and should be
> removed before performing any write request.
> Matt

Exactly Matt, and now that we have an append only file it's much
simpler to explain why this is so much needed.

The client performs:

SET a 10
EXPIRE a 60
(sleeps for 100 seconds)
INCR a

a will be 1, since the key is already expired after 100 seconds.
But what we have in the append only file? The same commands without
timings, so there is no delay between EXPIRE and INCR when Redis
re-read the file on startup (the same applies for master-slave
replication).

a would be 61 after reloading the file without such a semantic.

Time dependent behavior is not a good idea for Redis...

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay
Reply all
Reply to author
Forward
0 new messages