Re: Cache, Session and Auth Middleware and Vary: Cookie

Hi Tom, If the view is login required, then you must send 'Vary: cookie', > there is no option. Consider what would happen if you did not vary on > the cookie: > > Logged in user accesses the page via a caching proxy > Returned page is cacheable, no Vary header > Proxy stores page in cache > Not

Cache, Session and Auth Middleware and Vary: Cookie

Hi, I've just enabled caching for a Django application and it works great, but there is a small problem. As you know, Session middleware adds a Vary: Cookie header to the response and it is smart enough to do that only if the session has been accessed. This is all good, but the problem is that

Re: Question for Django ORM developers

On Wed, Feb 24, 2010 at 7:57 AM, Russell Keith-Magee wrote: > On Wed, Feb 24, 2010 at 12:20 AM, P.R. wrote: > > Hello, > > > > I have question about type of design patterns using in Django ORM. It > > is: Table Data Gateway, Row Data Gateway, Active

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

Nice explanation, but I can't see this documented it like this anywhere. If it isn't documented people have to interpret it based on what they would expect and apparently our expectations are different. Does Django enforce any other contracts defined on the models? What would happen if I accessed

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

Hi, Well, I'm not a django core developer, so my post probably won't weight that much, but I can't leave Luc with the feeling that that aren't other people that have the same opinion as him. Luc, I'm with you on this one :) First of all the problem is in an area of handling the mismatches