Method .cache(timeout) in QuerySet

I wrote wrong this part: "As my english is the best", I forgot the NOT part of the sentence... hehe ;)

Fixed patch wish key based on hash. This is because cache doesn't accept keys with 250+ characters.

Since I lost the detailed text that I wrote in the Django Snippet told above (that has been deleted), I am writing below exemples of use of the method.

Overriding get_query_set

This is an example for use cacheable request everytime.

class CategoryManager(models.Manager):
    def get_query_set(self):
        q = super(CategoryManager, self).get_query_set()

        return q.cache(300)

Single use

This is an example for use cacheable request just for that line.

lista = Video.all().cache(300)

You should:

• Remove the "#-----"
• Add test cases to test this new behaviour, like:
  • Run a query cached,
  • Modify objects,
  • Rerun the query cached, see it's not changed
  • Rerun without .cache(), see it's changed
• Patch the documentation to report about this method.

Anyway I think that should go in post-1.0 ;)

And I'm not sure if running a query without cache should invalidate caches of that same query, but that could waste resources checking if cache exists for every query, so better forget.

@telenieko

Thanks for advices :) I known that I need to improve the patch, but I'm waiting for the merge of 1.0-final (with newforms-admin) to do this :)

Updated patch with cache method

Tests and documentation done. Also the proxy method in Manager class

Two other approaches to do that:

• http://code.google.com/p/django-orm-cache/
• http://www.djangosnippets.org/snippets/502/

but I still prefer the approach of this ticket, in my opinion is more simple and powerfull :)

I don't think this has a place in core at the moment. There are a lot of trade-offs you have to know about when doing caching like this (e.g. it assumes the data isn't changing rapidly enough for the caching to get unacceptably stale). It's already pretty easy to cache queries when you want them to be cached (and caching querysets with a key so they can be looked up later is probably better in most cases).

My feeling is that this is probably better done for now as a third-party thing that is invoked via a manager that provides a custom QuerySet? class. Making it work smoothly with other custom Queryset / Query classes might require a little work and that's something you can bring up on django-dev if it turns out to be hard (it would be nice to make it possible). But tying the caching stuff into the SQL producing stuff so tightly doesn't sit comfortably with me.

Leaving open for the time being in the hopes that another core developer will comment one way or the other, but I'm giving it a -1 at the moment.