Feature Request: Add `cacheExpireTime` to invalidation data store

[jwarykowski]

Hi, before I raise a PR I would love to add the following possible improvements:

1. Add an isExpired helper to return a boolean as to whether TTL has passed for record.

cache.client.isExpired(cache.client.identity(record)) => true | false

2. Add cacheExpireTime to the invalidation data store so we can see this next to the cacheTime of the record as defined below:

Do you see any implications with adding these improvements?

[danReynolds]

Hey there! Thanks for the suggestions. Let me follow up:

1. I think this is interesting, I'm wondering what a use case could be. Maybe you're looking to expire an entity on reading it that is unrelated to a TTL per-se, rather it's related to maybe some external state or the state of other entities? Is that what you're thinking of? Also if a TTL is specified for the entity type too, I assume the idea would be that this takes precedence of a conflicting TTL expiry rule?

2. This one I think could be solved with a utility function like cache.readEntityExpiration(ref) that would take the current cacheTime on the ref and then add its type's TTL to generate the expiration time lazily when queried vs storing that redundant info in the cache itself where it's just adding to the memory footprint. Thoughts on that?

Thanks for these proposals!

[jwarykowski]

Hey @danReynolds,

1. This first proposal was more around just understanding whether the ref that is in the cache has had its TTL expired. To do this currently I'm just doing something like the following:

  const expiredEntities = client.cache.expiredEntities();

  const isExpiredTTL = expiredEntities.find(
    (id: string) => id === client.cache.identify(item)
  );

This is pretty simple to be honest, perhaps we don't need a function for this but I though it could be nice to make this in one call. Note the reason I'm doing this is simply for debugging at the moment, I just want to show whether an entity has an active or expired TTL.

Screen.Recording.2022-06-25.at.7.33.05.pm.mov

2. The proposal you've suggested would solve issue 1 above, I understand your concern about the memory footprint as a large cache could store data that is never/rarely used etc, so I agree this could be a waste. However if I wanted to find out the exact time the TTL would expire this could be quite useful for debugging.

Perhaps we could have a function which returns a boolean and a function which which tell me the time it will expire?

• cache.readEntityExpired(ref) would return true or false
• cache.readEntityExpirationTime(ref) would return a timestamp value e.g 1519211809934

Note getting its cache time would also be quite useful:

cache.readEntityCacheTIme(ref) would return a timestamp value e.g 1519211809934

[danReynolds]

I agree! All three of those APIs sound useful. Feel free to look into that, I'd be happy to add them as well next week so whatever works.

[jwarykowski]

Hey @danReynolds, sounds great, I'll try and get around to this in the week 🙇