On Tue, Dec 6, 2005 at 9:37 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
...
> Looks like vary_on_get is the most popular choice. So here's how that
> might work:
>
> @vary_on_get('id')
> def my_view(request):
> id = request.GET.get('id', None)
To be clear, the generated cache key would still include anything
stated in the HTTP Vary heads, right?
Vary: Cookie combined with @vary_on_get() should still vary on Cookie.
> The remaining question is: What's the behavior if vary_on_get() isn't
> specified for a particular view? Do we cache everything (including
> separate cache entries for any combination of different GET
> parameters) or cache nothing (current behavior)?
I say cache nothing; doing otherwise is backwards-incompatible. I
realize that means a bunch of decorators on views if you want the
cache-everything behavior.
Assuming vary_on_get() with no parameters means no variance (other
than the HTTP Vary headers), then
perhaps we could write a helper to walk URLConf and apply a
vary_on_get() decorator to indicate cache-everything. People could
opt-in this way without having to go update all code.
(This does fall down if you're mixing reusable apps that expect
cache-nothing. Hmm.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
