I've been bitten by this behaviour before, with code that looked like an_object.related_object_set.delete()
where the foreign key could be null. On Thu, Dec 16, 2010 at 11:14 AM, Luke Plant <l.plant...@cantab.net> wrote: > On Thu, 2010-12-16 at 10:10 -0800, tonnzor wrote: >> My idea was to fix this in a very straight way - change ForeignKey >> behavior (the piece of code that generates many_set method) - so it >> doesn't take into account null. >> >> Let me explain a bit more. If foreign key is null - then there's no >> link between Many and One object. So it many_set should return empty >> set disregarding DB state. > > This isn't true if the field pointed to (i.e. primary key by default) > allows NULL values - in that case a ForeignKey field with a NULL value > can and should return a non-empty set of values when the related objects > lookup is done. Why is this necessarily true? NULL is explicitly defined as the absence of a meaningful value. NULL values are not supposed to compare as equal to each other (this is why you need to test for "IS NULL" in SQL, rather than "= NULL") As well, in SQL, a foreign key join like select * from A join B on (A.fk = B.pk) will not join rows where A.fk and B.pk are both NULL. I would expect to be able to safely perform a query like delete from A where A.fk = NULL knowing that no rows would be deleted, and I expected (before I discovered this behaviour) the Django ORM to do the same. -- Regards, Ian Clelland <clell...@gmail.com> -- 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.
