We moved to Redis.io!

How does one clear a timeout then generically (strings, lists, sets)? I'd have to know that my key is a string can call GET k then SET k v then EXPIRE k t. Can you please add a RMEXPIRE that works for strings, sets, lists, etc.?

Hello. To clear a timeout is not allowed for the same reasons specified in the "Restrictions with write operations against volatile keys" of this documentation page. The only way to do this is to read the value, delete the key, and recreate the value again.

expire command is not replicated in redis_version:0.900.

Can any one confirm?

That is correct, the issue is fixed in the git repository however.

See http://github.com/antirez/redis/commit/774230260ff61dbc143236f690ccc73048f7fdfe

SET A 1<br> EXPIREAT A 1266796909<br> 1<br> EXPIREAT A -1<br> 1<br> TTL A<br> -1 <br> EXPIREAT A 1266796909<br> 0<br> <br> Why?

Hello. How can I set an expiration for multiple keys (to use with MSET or MSETNX)?

Hello.

set dff 1   //dff=1
incr dff    //dff=2
expire dff 1000
get dff     //dff=2
incr dff    //dff=1, but must dff=3   <-- 
get dff     //dff=1

Hi all....I understand why writes cause volatile entries to be cleared out, it makes sense. I don't understand, however, why it is not permitted to specify a new EXPIRES value for an existing volatile entry. It seems to me that should be a safe operation. The only thing I can think of is that (depending on how the replication works) a slave could expire a key before receiving the new EXPIRES command from the master, so they'd get out of sync....but given that the key expiring is done by choosing a random chunk of keys and checking them for expiry, that makes me think that all expiring is probably done on the master and then the list of expired keys is pushed to the slaves, so this should be safe. Can someone shed some light on this for me? Thanks.

Typo in "Let's rework a bit hour example" in FAQ part

the PERSIST command is not usable in current stable 2.0.0