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. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
