#19253 closed Cleanup/optimization (fixed)
Refactor keyfunc from template cache tag
Reported by: | nosa_manuel | Owned by: | Tomek Paczkowski |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | sprint2013 |
Cc: | tomek@…, chrismedrela | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The code to generate keys is stuck in the middle of the render method of the cache tag node, and should be extracted so that it can be used to invalidate template cache fragments.
Patch available in a pull request here: https://github.com/django/django/pull/482
Change History (6)
comment:1 Changed 11 years ago by
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 Changed 11 years ago by
Cc: | tomek@… added |
---|---|
Keywords: | sprint2013 added |
Owner: | changed from nobody to Tomek Paczkowski |
Status: | new → assigned |
comment:4 Changed 11 years ago by
Cc: | chrismedrela added |
---|---|
Triage Stage: | Accepted → Ready for checkin |
comment:5 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:6 Changed 9 years ago by
I think this should have been put into django.utils.cache
where other cache related utilities including cache key generation happen already.
Is there a particular reason why this was put into a completely new module instead?
Note: See
TracTickets for help on using
tickets.
The only reason to refactor this is to expose it as public API - and so would need a slightly different approach.
The func should be exposed somewhere else - not in the template tag, perhaps in new django.core.cache.utils module
To avoid confusion with the make_key function on cache backends - it should be more explicitly named as
make_templatefragment_key
And it should be documented at the end of https://docs.djangoproject.com/en/dev/topics/cache/#template-fragment-caching - presumably explaining the use case for, presumably, cache invalidation based on the change of something else in the project.
Could you explain why you can't achieve what you are after with using template variables for the vary-on args that are set by the view, which would cache a new fragment as needed?