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
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
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
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
uding
> 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 va
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 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)?
ng 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)?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
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, 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
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
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 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
13 matches
Mail list logo
