Context: Followup from a discussion with @Atinux as he asked if it is possible to pass custom transaction options to defineCachedHandlerto allow setItem with custom ttl and allow invalidating caches. currently, some unstorage drivers support ttl inconsistently.
Currently, the caching layer, passively (on demand) invalidates cache entries on the next access. But it does not delete them during revalidation or in the background.
Actively (automatically by storage backend) invalidating caches, is pending for universal ttl support, which afterward, we can set it.
We might also find a strategy for passive invalidation (during revalidation if it fails for example) but not sure. Another option is for unstorage to support background gc.
Context: Followup from a discussion with @Atinux as he asked if it is possible to pass custom transaction options to
defineCachedHandler
to allowsetItem
with custom ttl and allow invalidating caches. currently, some unstorage drivers supportttl
inconsistently.Currently, the caching layer, passively (on demand) invalidates cache entries on the next access. But it does not delete them during revalidation or in the background.
Actively (automatically by storage backend) invalidating caches, is pending for universal
ttl
support, which afterward, we can set it.We might also find a strategy for passive invalidation (during revalidation if it fails for example) but not sure. Another option is for unstorage to support background gc.