You probably don't want to cache changes. Or if you do, it would be better done elsewhere (like a caching raid controller/w battery on your database machine). The usual cache patterns I've seen are:
1) Fetch from database 2) Store in cache with a reasonable timeout to that changes are reflected as the cache expires 3) Look in cache, if found return that. If not goto step (1) or 1) Fetch from database 2) Store in cache with a -long- timeout 2.5) Track changes to cached objects and update the stored information if it changes. 3) Look in cache, if found return it. if not goto step(1) since the changes won't be reflected as rapidly due to the long timeout, you can configure the post_save/post_delete/etc signals to automatically update the cached value every time a change is made to one of that models instances. This is what the django-cache-utils app is doing for you. The trick is that the more complicated your use, the more complex the cache invalidation is going to have to be. Another possiblity is that caching may be the wrong solution to your problem. If for example a web request need to do so a bunch of expensive operations, but does not need to do them interactively with your user, a solution like django-celery may be better. With celery the job gets scheduled for execution outside of the web request- response system (possibly even on another machine) and gives you a job id. This allows the user to get on with things, leaving the work to be done behind the scenes. If the user needs to know the results or state of the job you can use ajax or refreshing to check back using the id to retreive the results when the job completes. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
