Opened 15 years ago

Closed 13 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


It'd be convenient for the lookup API to have caching baked in.

Change History (8)

comment:1 Changed 15 years ago by wojtek@…

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.

comment:2 Changed 13 years ago by Gary Wilson <gary.wilson@…>

Summary: Add a cache=NUM_SECONDS argument to get_list and get_objectAdd a cache=NUM_SECONDS argument to QuerySet
Triage Stage: UnreviewedDesign 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 Changed 13 years ago by anonymous

Resolution: fixed
Status: newclosed

comment:4 Changed 13 years ago by anonymous

Resolution: fixed
Status: closedreopened

comment:5 Changed 13 years ago by tbarta@…

Cc: tbarta@… 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.

    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 in reply to:  5 Changed 13 years ago by James Bennett

Replying to

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 Changed 13 years ago by anonymous

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 Changed 13 years ago by Jacob

Resolution: wontfix
Status: reopenedclosed

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.

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