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
Now that --modtime is supported it's possible for a cached invocation to become functionally unreachable1 but remain in the cache for an extended period of time. For example:
bkt --ttl=1d --modtime=.git/FETCH_HEAD -- git status
Any cached status will become unreachable whenever FETCH_HEAD is updated (i.e. after git fetch / git pull) but presently bkt can't actually clean up the data until the TTL expires. In principle bkt could clean up all existing cached data linked to a given file whenever its modtime changes.
Furthermore, if this functionality is added such commands could be allowed to not set a TTL at all (if they want) and simply rely on modtime invalidation.
This would be a somewhat sizable refactoring of the Bkt and Cache APIs, but it's probably worth the effort.
Footnotes
yes a file could theoretically be set to a prior modtime, either manually or after a clock change, but this is uncommon and a cache miss in such circumstances is probably acceptable. ↩
The text was updated successfully, but these errors were encountered:
This is a breaking change but the default behavior is arbitrary and it's
unlikely most users actually need or want this TTL. Furthermore, making
this change will enable introducing other expiration mechanisms in the
future. More details in #48 and #27.
Now that
--modtime
is supported it's possible for a cached invocation to become functionally unreachable1 but remain in the cache for an extended period of time. For example:Any cached
status
will become unreachable wheneverFETCH_HEAD
is updated (i.e. aftergit fetch
/git pull
) but presentlybkt
can't actually clean up the data until the TTL expires. In principlebkt
could clean up all existing cached data linked to a given file whenever its modtime changes.Furthermore, if this functionality is added such commands could be allowed to not set a TTL at all (if they want) and simply rely on modtime invalidation.
This would be a somewhat sizable refactoring of the
Bkt
andCache
APIs, but it's probably worth the effort.Footnotes
yes a file could theoretically be set to a prior modtime, either manually or after a clock change, but this is uncommon and a cache miss in such circumstances is probably acceptable. ↩
The text was updated successfully, but these errors were encountered: