Open favonia opened 1 month ago
@favonia Hi, could you provide an example that would illustrate your use case?
@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.