1👍
If the transformation can be represented as complex queryset, you could evaluate it in template w/o caching in view. If not, you could
- do the logic in template tag inside cache block
- wrap logic and pass it to render, typically in the form of closure or model method
- only do view cache, as long as rendering process is simple
- check possibility of SSI w/ help of TemplateResponse
- write code to check-and-use template cache in view, w/ considering of possible race-write and dog-pile issue.
Furthermore, for queryset cache, you could try johnny-cache, as well as django-cache-machine.
0👍
You don’t need to cache in the view AND in the template fragment. The idea of caching is, once you’ve something cached, you get it from cache until the cache key expires.
Caching the database results in the view implies writing some code specific for the view logic, that you’d probably need to change every time the logic changes.
Caching the template fragment is a better approach, because even if you change the template “logic”, as long as you keep the fragment inside a cached block, the caching will continue working.
Also IMHO, the more close to the final response you cache, the more reliable the cache logic will be.
- [Django]-Django saving form strings in database with extra characters (u'string')
- [Django]-Postgres connection details in django and chef