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 <tevans...@googlemail.com> 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<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.
