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 <luc.saf...@gmx.net> 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 <luc.saf...@gmx.net> 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" 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<django-developers%2bunsubscr...@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.
