Opened 8 years ago

Last modified 3 years ago

#5815 new New feature

Adds per-view cache refreshing (clearing)

Reported by: k0001 Owned by: nobody
Component: Core (Cache system) Version: master
Severity: Normal Keywords: cache refresh clear
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

This patch adds the possibility to clear(refresh) cached data per view.

SmileyChris sugested it would be good to add another key to the cached keys where we could keep track of all the different cache_page_key hashes, so we that can delete those then.

It is possible to clear the cache for an specific view, to achieve that, you
should tell your view's url path (and optionally, a key_prefix) to
clear_cache_for_path(path, key_prefix=None).

    from django.utils.cache import clear_cache_for_path
    
    # clear the all cached data for path '/blog/posts/2/'
    clear_cache_for_path('/blog/posts/2/')

Note that it will delete every page cached from matching this path, Vary headers
doesn't matter.

NOTE: Thanks SmileyChris for your help and supervision with this.

Attachments (1)

add_cache_clear_feature.diff (3.7 KB) - added by k0001 8 years ago.
adds per-view clear cache support

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by k0001

adds per-view clear cache support

comment:1 Changed 8 years ago by Simon G.

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 8 years ago by jacob

  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted

I like the idea. However, I'm -1 on the implementation -- adding another key to the cache seems unnecessary.

comment:3 Changed 8 years ago by SmileyChris

I don't see how we can get around adding a key to index the view's cache keys. Since they are hashed, there's no way of retrieving them with the current cache API (you'd need some type of .get_starts_with() method which I'm not sure would be even possible)

comment:4 Changed 7 years ago by julianb

One could argue that you are doing something wrong if you need per-site or per-view cache clearing.

If you have a page that changes more than once in a month, you are better off using the cache template tag. This allows you to share cached content between views and the keys can be deleted more easily when something got updated. With per-view caching you always cache the whole page, for every page. Imagine how often you cache your header or footer that way if you have a larger site.

comment:5 Changed 4 years ago by gabrielhurley

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 4 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 4 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:8 Changed 3 years ago by aaugustin

  • Triage Stage changed from Accepted to Design decision needed

Setting to DDN since there's some disagreement between Jacob and Chris.

Explicit cache invalidation can be useful in some scenarios, it'd be nice to support this.

comment:9 Changed 3 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

If there's really not a better implementation (perhaps there isn't) then I'm OK with this going in as-is.

Note: See TracTickets for help on using tickets.
Back to Top