On Saturday 06 February 2010 16:32:35 Luc Saffre wrote: > Hello, > > I am trying to understand why Luke closed my ticket #12801 > (http://code.djangoproject.com/ticket/12801). > > Luke, don't get me wrong. Thank you for having taken the time to > decide upon this and my other ticket #12708. I agreed with you for > marking #12708 as invalid, because I didn't understand the real > problem when I wrote it, so the formulations in that ticket are > rather confusing. > > But #12801 now shows so clearly an odd behaviour which should at > least be documented if it cannot be fixed. Marking #12801 as a > duplicate of an invalid ticket means to me that I should not even > *try* to write a patch. Is that really what you want to say?
Yes, that is what I meant to say. I'll defend my opinion here, and let others weigh in. The issue is what should happen with the following model: >>> class Foo(Model) >>> a_date = DateTimeField() >>> bar = ForeignKey(Bar) >>> >>> f = Foo() >>> f.bar The current behaviour is that a 'DoesNotExist' exception is thrown, because f.bar_id = None, and the field is not nullable. This is different from other uninitialised fields, which return None e.g. >>> assert f.a_date is None Luc wants the behaviour to be the same i.e. no DoesNotExist exception for an uninitialised ForeignKey field. My response (in a more expanded form here than on the ticket): 1. ForeignKey fields are different from simple values, in that they cause database lookups (the only logical exception being nullable foreign keys with a PK of None), so it's reasonable for them to behave differently. 2. When that lookup occurs, whenever the PK value is not in the database, you get an exception. So if the PK value was 123456 and that did not exist, you would get an exception. So this behaviour is consistent with other values of Foo.bar_id, and changing it would break that consistency. 3. You currently get an exception if you attempt to set f.bar = None. So, 'None' is never the value of a non-nullable foreign key field. The proposed change would break that symmetry - you would not expect the 2nd line of the following code to throw an exception if the first did not: >>> assert f.bar is None >>> f.bar = None If we changed Django to accept the first line, surely we also need to change it to accept the second (which would be a bad idea, I think we'd agree). 4. There is an easy work-around if you are allergic to exceptions, which is to check the PK value (f.bar_id in the above case). Thanks, Luke -- "Yes, wearily I sit here, pain and misery my only companions. And vast intelligence of course. And infinite sorrow. And..." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- 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.
