Opened 11 years ago

Closed 10 years ago

#5 closed enhancement (wontfix)

Add a cache=NUM_SECONDS argument to QuerySet

Reported by: adrian Owned by: adrian
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: UI/UX:


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

Change History (8)

comment:1 Changed 11 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 10 years ago by Gary Wilson <gary.wilson@…>

  • Summary changed from Add a cache=NUM_SECONDS argument to get_list and get_object to Add a cache=NUM_SECONDS argument to QuerySet
  • Triage Stage changed from Unreviewed to 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 Changed 10 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 10 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:5 follow-up: Changed 10 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 10 years ago by ubernostrum

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 10 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 10 years ago by jacob

  • Resolution set to wontfix
  • Status changed from reopened to 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.

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