jellydator / ttlcache

An in-memory cache with item expiration and generics
MIT License
927 stars 117 forks source link

Feature request: set without extending the expiration or adding new items #144

Open favonia opened 1 month ago

favonia commented 1 month ago

This is related to #115 and #121.

The logic of PreviousOrDefaultTTL could still (conceptually) extend the expiration time if the item just expired and then got recycled. I wish to have a genuine PreviousTTL that would not add any new item if the item does not exist, assuming that the item was just recycled. One can argue that this behavior is perhaps closer to the spirit of #115 than #121, and that any reasonable use of PreviousOrDefaultTTL should be compatible with this new PreviousTTL.

Current workaround

There's already a way to implement this with the current ttlcache: instead of saving the data directly into the map, save a pointer to the data. Then, one can update the data without calling Set, avoiding expanding the expiration and potential new items altogether. I still feel we should consider this alternative PreviousTTL if PreviousOrDefaultTTL already exists.

swithek commented 1 month ago

@favonia Hi, could you provide an example that would illustrate your use case?

favonia commented 1 month ago

@swithek Sure, here it is: I'm developing an application for a web API that supports listing all items, updating an item, creating an item, and deleting an item. "Listing all items" is potentially expensive and I want to cache it. In particular, I will calculate the supposed current list after successful updates, creations, or deletions of an item without re-downloading the list from the server. (The server indicates whether an individual operation succeeds without returning the whole list.) However, I still want to sync the whole list with the server from time to time.

A natural way to achieve this is to use TTL to remember when to download the whole list from the server again. Before that, when calculating the emulated new list locally and updating the cache, I wish to maintain the same TTL and avoid adding new ttlcache items because the local emulations are based on the original cached results. The PreviousTTLOrDefaultTTL unfortunately could accidentally create a new ttlcache item if it just got expired and recycled (under a race condition), delaying the schedule to sync with the server again.

BTW, maybe the name PreviousTTLOrSkip or something like that would be more descriptive than PreviousTTL?