[feature] Per item TTL in TTLCache

[judahrand]

Would it be possible to implement a per-item TTL? This could still default to the cache's global TTL if not set.

[tkem]

Sure, I played with the idea myself a few years ago... ended up with a custom set method that seemed too exotic to include. Anyway, most use cases I came across didn't really need a per-item TTL, but rather one of a limited set of predefined TTLs. Long-, mid- and short-lived items, for example. Putting these into different caches with different TTLs usually turned out to be a simpler solution.

[judahrand]

Not something that you'd be keen to merge into master then?

My use case revolves around rate limiting. Specifically the combination of these two issues:

• [feature] CacheTTL Store option sigmavirus24/rush#11
• [feature] TTL on keys sigmavirus24/rush#6

Part of the point of separating the rate limiter from the the storage backend in the Rush package is to remove the need for duplicating the functionally into an object per rate limiter. You could imagine this even more so with external stores like Redis where you might end up running multiple connections. Each of these rate limiters could potentially want different TTLs.

I happened across the TTLCache implementation in the package which if I'm not mistaken is very nearly a full TLRU caching algorithm. It just lacks the per key TTL. I'm very keen to use it in Rush to offer a more robust alternative to the current 'DictionaryStore'.

[tkem]

Well, not quite ;-)
However, I've been toying with the idea of a TLRUCache in branch wip/tlru. It's basically replacing the numeric cache-wide TTL argument with a function, which receives the to-be-cached value as its sole argument. So the TTL/TTU can be a property of the value (e.g. derived from a cache header for an HTTP response) or some function "defined by the local network administrator according to local policies and requirements" as stated in https://arxiv.org/pdf/1801.00390.pdf.
I haven't put too much thought into that, yet, so I'd appreciate if you could share your thoughts on that approach!

[malversan]

Not directly related to the question, but...

That TLRUCache can be easily integrated into the current TTLCache implementation with no need of an additional class, and maintaining TTLCache backwards-compatible.

Just check in object creation if "self.__ttl" is "callable()", and take it into account when setting the inserted item expiration time.

[dberardo-com]

is it possible to get the remaining TTL for a single item in the cache?

like cache.getRemainingTTL(key)