Automatically (with help) invalidate cache when code changes
See original GitHub issueSometimes a change in the code should trigger the invalidation of the cache. The idea is to add the version
optional parameter to cache_memoize
, defaulting to None
. Then the version, if not None
, would be added to the cache key.
We could use it like this:
@cache_memoize(60)
def f(...):
Then we fix a bug in f
and write:
@cache_memoize(60, version=1)
Another bug fixed (so many 🐛 🪲 ) :
@cache_memoize(60, version=2)
So, when the fixes are deployed the cache will be invalidated, instead of returning a wrong cached value.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Automating Cache Invalidation With Change Data Capture
This allows to invalidate affected cache entries in near-realtime, without the risk of stale data due to missed changes. If an entry has...
Read more >Good way to invalidate cache entries when view code changes?
You can use cache_digest. It does exactly what you need: invalidates cache fragments automatically when the view is changed. This way you don't...
Read more >Invalidate caches | IntelliJ IDEA Documentation - JetBrains
When you invalidate the cache, IntelliJ IDEA removes the cache files for all projects ever run in the current version of the IDE....
Read more >Clear your cached content automatically - Project Shield
Clear your cached content automatically ; Change Key button under 'Cache Invalidation API' in your site's ; request.json, invoke the command: ; /some/prefix...
Read more >Invalidate cache when rules change #3770 - eslint ... - GitHub
We should automatically invalidate the cache when the configuration used to test the file was changed. This will allow people to use the ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes. It may be as well a more generic option (e.g.
suffix
), just something that is added to the key.I vote for
version
.Django itself does support the
version
argument: https://docs.djangoproject.com/en/3.2/topics/cache/#cache-versioningIt should be easy to add just one more pass-through argument to
cache_memoize
.