Opened 19 years ago
Closed 18 years ago
#5 closed enhancement (wontfix)
Add a cache=NUM_SECONDS argument to QuerySet
Reported by: | Adrian Holovaty | Owned by: | Adrian Holovaty |
---|---|---|---|
Component: | Metasystem | Version: | |
Severity: | normal | Keywords: | |
Cc: | tbarta@… | Triage Stage: | Design decision needed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It'd be convenient for the lookup API to have caching baked in.
Change History (8)
comment:1 by , 19 years ago
comment:2 by , 18 years ago
Summary: | Add a cache=NUM_SECONDS argument to get_list and get_object → Add a cache=NUM_SECONDS argument to QuerySet |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
This could get tricky if you've got the same query in different places and don't want them cached the same.
comment:3 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 by , 18 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
follow-up: 6 comment:5 by , 18 years ago
Cc: | added |
---|
It would be nice to be able to plug Django into something like Memcache and turn on caching, but I would like to see it above the database layer rather than below it.
try: polls = memcache.get('polls_blah') except CacheNotFound: polls = Polls.objects.all() memcache.set('polls_blah', list(polls), memcache.FIFTEEN_MINUTES)
Putting caching into the database layer IMHO adds too much magic, and could produce weird results when cache behavior is unexpected. Forcing the app developers to use a cache explicitly keeps them "in the know" about what they're doing. There could even be a Django shortcut like
polls = get_cached('polls_blah', lambda: Polls.objects.all(), cache.FIFTEEN_MINUTES)
comment:6 by , 18 years ago
Replying to tbarta@gmail.com:
You've mostly described what Django's cache API already does -- you choose a cache backend (memcached is an option), and then a standardized API lets you talk to it via cache.get
and cache.set
. See the cache documentation for more information.
comment:7 by , 18 years ago
Thanks for the pointer, ubernostrum. That cache documentation describes exactly what I was suggesting in my first example.
Given that Django has fairly complete caching middleware already available, I'd recommend that this either be a shortcut (something like my get_cached
example above) or just be skipped. The convenience of embedding caching into the database layer is (IMHO) outweighed by the unnecessary coupling.
If an application wants to use the admin interface but still support model caching, invalidation could simply be put in the model's save
method, right?
comment:8 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
This has languished long enough without any real interest. I'm marking wontfix given that this would only be sugar for the existing cache api.
We're working on a caching framework which would also cache listings and handle automatic invalidation when objects are changed. The results will be posted within a few days.