You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
favonia
changed the title
Feature request: set without expanding the expiration or adding new items
Feature request: set without extending the expiration or adding new items
Aug 11, 2024
@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?
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 genuinePreviousTTL
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 ofPreviousOrDefaultTTL
should be compatible with this newPreviousTTL
.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 callingSet
, avoiding expanding the expiration and potential new items altogether. I still feel we should consider this alternativePreviousTTL
ifPreviousOrDefaultTTL
already exists.The text was updated successfully, but these errors were encountered: