Right now, the Django cache system doesn't cache pages that have GET
parameters. This is because GET parameters don't necessarily influence
the output of the page. For example, if the page example.com/foo/ is
cached, anybody could simply add a "?bar=baz" to the URL and Django
wouldn't know whether
Picking up an old thread (because it is still relevant)
On 6 Dec 2005, 15:37, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> 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
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 stil
On Nov 2, 2:52 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Assuming vary_on_get() with no parameters means no variance (other
> than the HTTP Vary headers), then [...]
That seems confusing - the decorator name seems to imply that it would
vary on any get attribute (even though this is the def
On Sat, Nov 1, 2008 at 8:32 PM, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> On Nov 2, 2:52 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>> Assuming vary_on_get() with no parameters means no variance (other
>> than the HTTP Vary headers), then [...]
>
> That seems confusing - the decorator name see
I really like the idea of the explicit GET params passed.So I'm +1
especially on solution #3. I actually had never realized it wasn't
caching pages with GET params, luckily though, any pages where I use
this decorator don't fluctuate like that :)
On Nov 1, 7:51 pm, "Jeremy Dunck" <[EMAIL PROTECTE
On Nov 1, 2:52 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> 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.
>
Yes.
>
> I say cache nothing; doing otherwise is
+1On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
Right now, the Django cache system doesn't cache pages that have GETparameters. This is because GET parameters don't necessarily influencethe output of the page. For example, if the page
example.com/foo/ iscached, anybody could simply add a
On Dec 6, 2005, at 12:28 AM, Adrian Holovaty wrote:
Finally, along those lines, we could introduce a vary_on_get
decorator, which, used with the NO_GET_PARAMS setting, would be an
opt-in signifying a view *does* rely on query string. This could be
for stuff like search engines, which do vary bas
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>Finally, along those lines, we could introduce a vary_on_get
>decorator, which, used with the NO_GET_PARAMS setting, would be an
>opt-in signifying a view *does* rely on query string. This could be
>for stuff like se
Jacob Kaplan-Moss wrote:
This sounds like the right idea to me: explicitly state which GET
params invalidate the cache.
So when the view's code change during development one should alsways
remember to update this invalidators list. Not very DRY :-(
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> So when the view's code change during development one should alsways
> remember to update this invalidators list. Not very DRY :-(
Except it's a decorator, so it's right there with your view code.
--
"May the forces of evil become confused on the
James Bennett wrote:
Except it's a decorator, so it's right there with your view code.
But still you have to blindly copy strings from code to decorator
parameters.
On Dec 6, 2005, at 2:35 PM, Jacob Kaplan-Moss wrote:
On Dec 6, 2005, at 12:28 AM, Adrian Holovaty wrote:
Finally, along those lines, we could introduce a vary_on_get
decorator, which, used with the NO_GET_PARAMS setting, would be an
opt-in signifying a view *does* rely on query string. This
>Finally, along those lines, we could introduce a vary_on_get
>decorator, which, used with the NO_GET_PARAMS setting, would be an
>opt-in signifying a view *does* rely on query string. This could be
>for stuff like search engines, which do vary based on the query string
>(e.g. /search/?q=foo). In
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> But still you have to blindly copy strings from code to decorator
> parameters.
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to implement
James Bennett wrote:
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to implement that directly in the view syntax
(since not everyone will be using caching). The proposed decorator
does
Don't you want to use my cache algorithm, proposed here:
http://groups.google.fi/group/django-developers/browse_thread/thread/fdc59b0b46502ede
?
It is able to handle GET/POST parameters (via converting these
parameters to the array and futher hashing array to the string, which
will be used as an
On 12/6/05, hugo <[EMAIL PROTECTED]> wrote:
> +1 for vary_on_get, that fits nicely into the current scheme and just
> sounds right to me.
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
On 12/6/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
The remaining question is: What's the behavior if vary_on_get() isn'tspecified for a particular view? Do we cache everything (includingseparate cache entries for any combination of different GETparameters) or cache nothing (current behavior)?
Q
20 matches
Mail list logo
