I have a patch I'd like to contribute, if you guys would like. This 
adds a new feature; I'm not sure if this conflicts with other 
development or sort of steps on other functionality but let me give 
you the background and what I did. 
For an e-commerce site I'm working on we needed a solution for fast server-side carts. After looking at a few options Redis made the most sense. We brought up a Redis server (as well as a slave, for replication) and store carts as a session ID mapping to a hash object (i.e. HSET and HGET).
To eliminate cruft from abandoned carts I used EXPIRE so that old carts will idle away after some generous amount of time. I realized that changes to a hash that's set to EXPIRE will actually eliminate all items in the cart, due to EXPIRE semantics. I worked around it with a complete hash read + rewrite with new data, followed by a new EXPIRE.
That works (it's in production now) but the reading, deleting, re- writing, and EXPIRE-ing might get costly. I added a new function "IDLE" that's similar but allows changing of something that's set to IDLE without destroying all the state. Things that are idle and untouched (read, written to) get deleted like the EXPIREd items do.
This doesn't address all the issues as I saw discussed previously on the FAQ about updating items set to EXPIRE, namely the ones concerning replication and replays from the binary log. Regardless I see more grumblings from people wanting to change EXPIRE-ing stuff than people concerned with those (indeed, legitimate) issues. So I'd like to release this in the hopes the community finds this useful. (Perhaps a warning, in documentation form or a message spit out at runtime, would help prevent ill effects.)
I hope you guys find this patch useful. This was written as part of my usual job at Sony Music Entertainment, supporting stores on www.sonymusicdigital.com. I just got consent to release this little bit of code to the BSD-licensed project.
My gmail account (in case that's necessary for me to add files under the project in Google Code) is:
I can be contacted there if you have any further questions.
Thanks for creating Redis! I hope this contribution is at least partial payback. :)
Steve O'Brien's gravatar image asked Jul 26 2010 at 12:55 in Redis-Db by Steve O'Brien

4 Answers

Hello Steve, thank you for your patch and the nice write up of your use case. In this days I'm fixing the problem in Redis master in a definitive way, that is allowing writes against expiring keys but without violating consistency.
This should solve all the issues, I'm working on this currently so I expect this to be available in one week more or less.
Cheers, Salvatore
Salvatore Sanfilippo's gravatar image answered Jul 27 2010 at 01:31 by Salvatore Sanfilippo
Looking forward to this change! I've always found EXPIRE counterintuitive, great news.
Alan Kennedy's gravatar image answered Jul 27 2010 at 02:06 by Alan Kennedy
Steve, Salvatore, Thanks, I am down on my knees with tears in my eyes, you can't imagine how this is going to take away on of two pains taht I suffer with Redis (everyhing else is A1)
Looking forward for the new version.
Steve,
I proposed a while ago a similar KEEP_UNTIL command, but as you can see Salvatore's plans point more to the core.
Salvatore,
By the way, heavily testing latest RC with _heavy_ use of more or less all the structures, and it has been working like a charm.
Thanks a lot for such excellent code,
-- Anbal Rojas Ruby on Rails Web Developer http://www.google.com/profiles/anibalrojas
AnÝbal Rojas's gravatar image answered Jul 27 2010 at 05:42 by AnÝbal Rojas
Excellent! Then we'll be looking out for this new EXPIRE functionality and keep our code as before (do a read/write on the hash, and set EXPIRE again). Actually, will it be so that EXPIRE can be set on an already-EXPIRE'd object? We'd need that to keep the "idle" functionality -- where something that hasn't been read/written goes away (there's a "moving" expiration date, not just a single point set at creation time).
Thanks!
2010/7/27 Anbal Rojas
Steve O'Brien's gravatar image answered Jul 27 2010 at 07:35 by Steve O'Brien
Facebook Google+ Twitter Linkedin
 Discussion Overview

 Group: Redis-db

 asked: Jul 26 2010 at 12:55

 active: Jul 27 2010 at 07:35

 posts: 5

 users: 4

Related Groups
Redis-db