Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Add ability to expire members of a set #135

Closed
mwhouser opened this issue Oct 11, 2011 · 9 comments
Closed

Feature Request: Add ability to expire members of a set #135

mwhouser opened this issue Oct 11, 2011 · 9 comments

Comments

@mwhouser
Copy link

@mwhouser mwhouser commented Oct 11, 2011

I'd like the ability to expire members of a set instead of the whole set.

The patterns described here http://groups.google.com/group/redis-db/browse_thread/thread/ad75cc08b364352b are not really feasable to me.

@antirez

This comment has been minimized.

Copy link
Owner

@antirez antirez commented Oct 11, 2011

Hello, unfortunately it is not in our plans! Sorry.

The one sentence rationale is: too complex, too memory consuming, more CPU needed.
In general the Redis model is: at level of key, many features: timeout, migration, sharding (Redis Cluster). At value level no fancy stuff.

@antirez antirez closed this Oct 11, 2011
@pietern

This comment has been minimized.

Copy link
Contributor

@pietern pietern commented Oct 11, 2011

This is not going to be added. There is a lot of extra memory involved, not to mention a lot of processing to make sure the elements would in fact be expired. The best way to implement this is to model this yourself, so you can stick to the bare minimum you need, while keeping all the flexibility to change things as you please.

The best pattern to model this is, in my opinion, using sorted sets with a score equal to the timestamp the member should expire. You can use ZRANGEBYSCORE <now> +inf to retrieve all elements that are not yet expired, and ZREMRANGEBYSCORE to expire items. Since a sorted set is also backed by a hash table, you retain O(1) TTL lookup.

Good luck.

@bobrik

This comment has been minimized.

Copy link

@bobrik bobrik commented Oct 11, 2011

+1 for sorted sets for this task. We use that for millions of integers in sorted set and it's ok

@xxxcoltxxx

This comment has been minimized.

Copy link

@xxxcoltxxx xxxcoltxxx commented Feb 18, 2016

+1

@dmitrypol

This comment has been minimized.

Copy link

@dmitrypol dmitrypol commented Sep 22, 2016

+1 would be a great feature (but obviously comes with a cost)

@bradvogel

This comment has been minimized.

Copy link

@bradvogel bradvogel commented Jun 20, 2017

+1

@duke-cliff

This comment has been minimized.

Copy link

@duke-cliff duke-cliff commented Aug 15, 2018

+1 It should be added. Memory is a give&take the user should consider. If we need the feature indeed, we will take the result of using more memory for sure.

LeSuisse added a commit to Enalean/tuleap that referenced this issue Oct 30, 2018
User seen per project are now stored in a zset so that the cache of
a project can be invalidated. The implementation is based upon the
recommendation/trick mentionned here [0] since it is not possible
to set an expiration on a member of a set.

No functionnal changes are expected from this contribution, the
invalidation of the cache when a project has a status change will
done in a future contribution. You can however check it works as
expected by dropping the set of seen username per project and check
that you get a cache miss:

   DEL apache_svn_project_set_<project_id>

While this contribution does not add a new feature, the error introduced
by commit 26cbef9
("Can't locate object method 'log' via package 'Apache2::Log::Request'")
is fixed.

To test, you need to redeploy the Tuleap.pm file to
/usr/share/perl5/vendor_perl/Apache/Tuleap.pm and restart Apache.

This is part of story #12160: have a clean way to suspend a project

[0] antirez/redis#135 (comment)

Change-Id: Ib056f7c3ca1c37bdf39de8c1106ff78e248c9970
@lukepighetti

This comment has been minimized.

Copy link

@lukepighetti lukepighetti commented Jul 6, 2019

What about tying a command to an EXPIRE? That way we can expire keys but trigger the deletion of a specific member of a set?

@inoas

This comment has been minimized.

Copy link

@inoas inoas commented Dec 15, 2019

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.