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 wojtek@…, 19 years ago

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 by Gary Wilson <gary.wilson@…>, 18 years ago

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 by anonymous, 18 years ago

Resolution: fixed
Status: newclosed

comment:4 by anonymous, 18 years ago

Resolution: fixed
Status: closedreopened

comment:5 by tbarta@…, 18 years ago

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.

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)

in reply to:  5 comment:6 by James Bennett, 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 anonymous, 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 Jacob, 18 years ago

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