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 logged on user requests the page via the proxy > Proxy retrieves cached, logged on version of the page and delivers it > to not logged on user > > Cheers > > Tom > > Yes, you are right, I haven't considered intermediary proxy caches. I was more concerned about what happens on the browser, as it seems that Firefox handles the Vary: Cookie as Vary: * (ie. it doesn't use its cache even if the session cookie is the same). So, it seems that if Vary: Cookie is set, the only place I can benefit from caching is on the server-side using Django's cache middleware. That works fine, but the cache is per-user and t doesn't seem that I can tell the caching middleware that I don't want that. It looks like if you have a webapp that requires login for all the pages, for pages that aren't user specific all you can do currently is to cache manually in the view. Is this true? Ideally, I would like to be able to use the caching middleware in this scenario by using only configuration + decorators. Does this makes sense? Thanks, Tamas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 I have @login_required on the
majority of my views and although they don't touch the session at all the
Vary: Cookie header will be added.
This is because the decorator has to get the user from the session so the
session middleware sees that the session has been accessed and sets the
header.
So a simple view like the one below will set the Vary: Cookie header,
although the result isn't user specific at all and this will prevent
caching.
@login_required
def some_view(request)
return HttpResponse('Some text')
The ideal solution would probably be to being able to access the session
without making the session dirty from framework code and then the auth code
could do just that.
Another possibility is to set the accessed flag back to False from the auth
code after accessing the user in the session, but I think that needs more
additional code, because request.user could be accessed from the view and I
don't think that will set session.accessed = True
Another possibility is to say that this is not a problem / can't be easily
fixed, but then we probably need a new decorator, so we can mark views as
@never_varies_on_cookie, because currently I don't think that we can avoid
having the Cookie added to the Vary header by SessionMiddlewar.
I thought I send an email to django-dev before raising a ticket to get some
other opinions on the issue.
Thanks,
Tamas
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
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 Record or Data > > Mapper? .. Personally I think that it's mix of Row Data Gateway and > > Data Mapper, but I want to ask You guys for sure :-) > > Honestly, I have no idea. The ORM wasn't constructed as an > implementation of a design pattern; we just built an API that made > sense. > > Yours, > Russ Magee %-) > :-) The Django ORM doesn't follow any of the EAA patterns exactly, and I don't think that it makes sense trying to force the design patterns names on it. Just because something does a good job at solving a problem it doesn't mean that it has to follow the documented design patterns. This is very similar to trying to force the MVC pattern on Django which also happens a lot. Not every web application framework that separates concerns properly has to be an MVC framework, no matter how fashionable MVC is. It is fine to be MTV :) All The Best, Tamas -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 a null=false, IntegerField for example? The question to ask here is WHEN are any contracts defined on the models enforced? I wouldn't expect anything to be enforced on a Model object that hasn't been persisted yet. So if I created a Model obejct but I haven't saved it yet and it hasn't been loaded from the DB I don't expect Django handling the ForeignKey attribute specially just as Django wouldn't prevent me setting a null=false IntegerField to a string or to null or throwing an exception when I access an attribute that hasn't been initialized. I'm saying that FK attributes should work consistently with other fields. I guess you are saying that FK attributes are different and they should work differently and this is where we disagree. In the owner = models.ForeignKey(Owner) example, yes I would expect getting an owner every time I access the owner attribute, but ONLY if I loaded the class from the DB or I already saved it. If the class isn't persisted it's just a plain Python class, there aren't any guarantees from Django and I can manipulate it however I like it. I don't see why a FK attribute would have to be special in this stage, because I don't even see a reason why you would do a select to fetch the Owner if the class isn't persisted. I completely understand that you don't want to change the existing behavior, I wouldn't change it myself. The difference is very small from a practical point of view so it isn't worth changing the behavior of Django. The docs might be improved, although you could just point people with similar views to this thread from now on :) All The Best, Tamas On Fri, Feb 12, 2010 at 8:01 PM, Tom Evans wrote: > I think the easiest way of understanding the behaviour is that > specifying a field like this: > > owner = models.ForeignKey(Owner) > > specifies a contract. The contract says that when you access this > attribute on an instance, it will only return an instance of an Owner > object or raise an DoesNotExist exception. > > Specifying a field like this: > > owner = models.ForeignKey(Owner,blank=True,null=True) > > specifies a very different contract. This contract says that accessing > this attribute will return either an instance of an Owner object, or > None if no owner has been specified. > > Both contracts are fully described in the documentation and fulfilled > by the ORM, so clearly this is no bug. Both flavours are available for > you to use, you simply have to decide what sort of contract you want > that attribute to have - if you expect instance.owner to return None, > then clearly you should be using a nullable foreign key. > > Cheers > > Tom > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 between the OO and the relational models, an area that should always cause discussions. So, Luc I guess you have to accept that this is a gray area and this is how Django's ORM works. Life goes on ... On the other hand, I do not understand how you can't see the point that Luc is making and how can you say that this makes sense from both the ER and ORM point of view. When you are working with your OO model the relationship between your models aren't represented by FK pointers. They should map to attributes of models or collections of models. FK based relations from the DB are represented by attributes and collections in the OO world and the ORM should take care of this mapping and making it transparent. In an ideal world you shouldn't use or even know about those _id fields when working with your OO models. Your working with your OO domain model that consists of Python classes and they should work like any other normal Python classes until you use save or load them (then the ORM kicks in and does the mapping). But until you do that, they should behave like Python classes so throwing DoesNotExist Exception when you access an attribute of a class feels a little bit strange. But of course our world is more pragmatic and I can live with the current implementation (and I hope Luc can do the same), but I can certainly understand why it feels strange to him and why he resists using _id fields while working with his models. All The Best, Tamas When you are working with your models On Wed, Feb 10, 2010 at 10:42 PM, Luc Saffre wrote: > Thank you, Henrique, for dropping in. > > As I said earlier, I don't want to bother the community with my > stubbornness or whatever it may be, so feel free to STOP READING HERE if > there is danger that this topic wastes your time. > > But to be honest, I must unfortunately say that I disagree also with > your explanations and that they (for me) confirmed my opinion. > > The expression `a_model.b_related` (where `a_model` is an instance of a > Model subclass that defines a field `b_related`) must always yield a > value in the Pythonic meaning (that is, it may yield None which is also > a value in Python). > > This same expression should raise an exception only if the field name is > wrongly spelled, or if an error occured when constructing the related > instance to be yielded (e.g. a failed DB lookup in the case of a FK > field other than None). > > A FK containing None (which is already now possible for nullable FK > fields) will never cause a DB lookup. > > Django guarantees that the value of a FK field will always be either > None or an instance of the related Model. > > Django never guaratees that every instance of a Model exists as a row in > the database. > > Django's current behaviour is not correct because it forces me to access > non-nullable FK fields differently than nullable ones. "In Python, > throwing exceptions for expected outcomes is considered very bad form" > [1]. Django should raise an exception only if I try to save an instance > with invalid data (for example None in a non-nullable FK field), but not > when I try to access any data, may it be valid or not > > [1] > > http://groups.google.com/group/comp.lang.python/browse_thread/thread/7d6191ecba652daf > > Luc > > > On 10.02.2010 6:28, hcarvalhoalves wrote: > > Maybe I can help Luc? I had similar questions once, because I started > > learning Django while deploying with a legacy database. > > > > On 8 fev, 20:31, Luc Saffre wrote: > >> You cannot ask user code to not even look at invalid data. I'm > >> not allergic to exceptions, but raising an exception when I ask for the > >> content of a field is not appropriate behaviour. > >> > >> Luc > > > > Raising the exception *is* appropriate behaviour, because when you > > access `a_model.b_related`, and `b_related` is a ForeignKey, you're > > not really accessing a value, but doing a lookup. This is consistent > > with both the ER and ORM model, where FK's are pointers, not values. > > And a FK pointing to a non-existant row *is* an exception. It means > > broken data. > > > > If you want the content of the *field*, what you really should check > > is `a_model.b_related_id is None`, which is checking if a pointer was > > set. Still, it doesn't guarantee that this pointer leads to anywhere > > valid. That's why dealing with the exception is a common idiom, "fail > > early, fail loudly", and particularly useful in this case to maintain > > DB consistency. > > > > I hope it helps in understanding the rationale behind the behaviour > > and why Luke marked as invalid. > > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" g
