Proposal: Include path and query parameters in view cache behaviour
Hi!
Currently query parameters are ignored when using the cache decorator
for views (only the path segment [3] is used to determine the key).
This impacts performance for Django sites where query parameters are
used for filtering and sorting of lists of items (a common use case).
I found an old discussion on this list [1] where Adrian Holovaty asked:
"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)?"
In ticket #4992 [2] I have proposed the following:
URL:s should be treated as opaque by the caching system. Consider
these sample URL:s
Request A: example.com/list/
Request B: example.com/list/?a=1&b=2
Request C: example.com/list/?b=2&a=1
If URL:s are treated as opaque, requesting A, B and C would create
three separate items in the cache. This would be the default behaviour
for the following:
@cache_page(60 * 15)
def list(request):
...
More fine grained cache behaviour could be specified with a
vary_by_param decorator like this:
@cache_page(60 * 15)
@vary_by_param("a", "b")
def list(request):
...
Requesting B and C above would create one item in the cache, i.e.
ordering is not important.
An idea would be to exclude the fragment part [3] from impacting the
cache as it is unlikely that developers rely on that for server side
behaviour (it is more likely used to give focus to a particular item
in the rendered HTML).
Kind regards,
Peter Krantz
[1]: http://groups.google.com/group/django-developers/msg/54d5750440d4bc93
[2]: http://code.djangoproject.com/ticket/4992#comment:9
[3]: http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: ANN: Django 1.0.1 beta available
hi i saw that a django tarball is now in pypi but the version ident is "1.0.1 beta 1". i am not completly shur if i am right, but the spaces in the version makes it impossible to use this version directly to download from pypi via setuptools, buildout etc. it would be nice to include django as a dependency in setup.py thx, bernd --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cache and GET parameters
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 combination of different GETparameters) or
> cachenothing (current behavior)?
>
URL:s should be treated as opaque in the default behaviour so there
would be a separate cache entry for each of these:
example.com/list/
example.com/list/?a=1&b=2
example.com/list/?b=2&a=1
However, the developer may know better and details which parameters
that affect the get request. This could be provided in a decorator for
the view method like this:
Vary by the entire URL (should be default behaviour):
@cache_page(60 * 15)
@vary_by_param("*") #This should not be required to get per full URL
caching.
def slashdot_this(request):
...
Only vary by values for parameter a and b (ignore everything else):
@cache_page(60 * 15)
@vary_by_param(["a","b"])
def slashdot_this(request):
...
I have added this to ticket 4992 [1] as I believe it would be of great
benefit for everyone filtering lists of data by URL parameters (a
common use case).
Kind regards,
Peter Krantz
[1]: http://code.djangoproject.com/ticket/4992
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Cache and GET parameters
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
-~--~~~~--~~--~--~---
Re: 1.0.1 Feature UserProfile inline Filter in User
This seems to be part of it. I'm not sure if there is a sort_by fix in
there or not. It would be nice to be able to pass some of these fields
to the add user form. It would look much more uniform.
On Oct 31, 6:00 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> This just seems like a generalization of
> this:http://code.djangoproject.com/ticket/3400
>
> On Oct 31, 7:28 pm, Cornbread <[EMAIL PROTECTED]> wrote:
>
> > I've ran into an issue I think that many will run into.
>
> > In our project we have a profile for each user and we have integrated
> > that inline with the user settings page. We have also added items from
> > the profile (address, city, state, zip, is_boss, etc) into the auth
> > users view.
>
> > The issue comes up when we want to filter through those users by our
> > user profile items.
>
> > I'm not extremely familar to the inner workings to django. I was
> > thinking that it would be nice in the admin when registering the
> > Profile maybe in Meta: show_user_profile. then user_profile_fields =
> > ('address', 'city', 'state', 'zip', etc).
>
> > Reported here:http://code.djangoproject.com/ticket/9463
>
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Proposal: remove auth context processor dependancy for Admin
I regards to http://groups.google.com/group/django-developers/browse_thread/thread/2bad3ad84e9beb81 One aid in this area would be to remove the dependancy of context_processor.auth in the Admin world (which most certainly needs the user, messages and perms in the context) Admin can detect if it is present, and use it, otherwise it would simply "add" the three vars (user, messages, perms) to the context itself. I think all it requires is to move the calls to "template.RequestContext" to "self.RequestContext" inside of contrib.admin.site.py .. making it backward compatible bo --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: remove auth context processor dependancy for Admin
On Sat, Nov 1, 2008 at 9:45 AM, bo <[EMAIL PROTECTED]> wrote: > One aid in this area would be to remove the dependancy of > context_processor.auth in the Admin world (which most certainly needs > the user, messages and perms in the context) You can already do this - simply make your own subclass of AdminSite and override check_dependencies -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: 1.0.1 release blockers?
On Nov 1, 1:38 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > > Really, there is not reluctance to get input on what should be fixed before > 1.0.1 is released. It's just that input in the form of working patches with > tests and doc is far more valuable than a simple bit on a ticket. The list > of tickets that are ready for checkin is not so big (and some of them are > enhancements so not candidates for 1.0.1.) that we need some other bit to > say "look at this before releasing 1.0.1". #8898 and #9482 are both simple bug fixes with patches that remain unreviewed. #9214 is a simple backwards compatible enhancement with patch. I'm reluctant to mark them "ready for checkin" as I am the reporter, but it's been 1-2 months for some of these with no review from anybody, and at least the first two are very simple fixes for bugs with no change in functionality. How should one get attention for these tickets? http://code.djangoproject.com/ticket/8898 http://code.djangoproject.com/ticket/9482 http://code.djangoproject.com/ticket/9214 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cache and GET parameters
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 default) - at least that's how I'd look at it if I didn't know otherwise. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Cache and GET parameters
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 seems to imply that it would > vary on any get attribute (even though this is the default) - at least > that's how I'd look at it if I didn't know otherwise. @vary_on_get(None) ? :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: 1.0.1 release blockers?
On Sat, Nov 1, 2008 at 9:14 PM, Tai Lee <[EMAIL PROTECTED]> wrote:
>
> #8898 and #9482 are both simple bug fixes with patches that remain
> unreviewed. #9214 is a simple backwards compatible enhancement with
> patch.
>
> I'm reluctant to mark them "ready for checkin" as I am the reporter,
> but it's been 1-2 months for some of these with no review from
> anybody, and at least the first two are very simple fixes for bugs
> with no change in functionality.
>
> How should one get attention for these tickets?
For each of these you mention, I see a reason it has not been committed,
which I'll describe below. In general, what will get fastest attention for
1.0.1 are clear bugs with patches that include tests and doc if
appropriate. If it sounds more like an enhancement than a bug, it's not
likely a candidate for 1.0.1. If it doesn' t have tests, it stands less
chance of getting in. If there's confused discussion in the ticket that
doesn't seem to have come to a clear consensus on the right answer, that'll
likely slow things down.
http://code.djangoproject.com/ticket/8898
I suspect this one may be stalled because it is in design decision needed
state with a last comment that makes it sound like the existing patch (added
before the last comment) is not correct and that the right fix will require
changes that are potentially backwards-incompatible ("users should be guided
to use X if they want to use Y"...how is that different from what users are
guided to do today and is there something they can do today that won't be
allowed after this fix is made?)
The bug sounds like it should be fixed, but that last comment makes it sound
like a proper fix is not yet available. Therefore not something that can
easily be simply committed but rather will require someone to spend some
time researching the history of this type of field to make sure the right
fix is developed. This rather conflicts with what you say above about this
being a simple fix, so please clarify in the ticket if that last comment and
move to design decision needed was not meant to raise a red flag that the
initially posted fix was not all that was necessary to fix this problem.
> http://code.djangoproject.com/ticket/9482
This one is only two days old. Give it time. But there's an easy
workaround (set the environment variable yourself before calling whatever
script you are runnig), this is not something covered by the test suite so
can't be tested to ensure it really doesn't break anything ("I can't see how
this could possibly break anything" are some famous last words, and believe
me I've said them myself), and it seems like a bit of an edge case (I
haven't heard a lot of people needing to put code in a project's __init__.py
file) all of which argue to me that it might not be a good candidate for
1.0.1. But that's just me, and it is only two days old.
> http://code.djangoproject.com/ticket/9214
This one reads to me like a feature request, not a bugfix. (You even say
above it is an enhancement.) 1.0.X is bugfixes only so I'd be surprised if
something like this goes into it.
Karen
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
