> No, it is not the case that null=True is disallowed for FKs, but it
> probably should be.
I've just been reading the code in django.db.models.fields.related,
and there's a pretty clear indication that the Django developers
explicitly wanted ForeignKeys to be nullable. In the RelatedManager
class, which is dynamically created by the
ForeignRelatedObjectsDescriptor class, the following appears:
class RelatedManager(superclass):
# ...
# remove() and clear() are only provided if the ForeignKey
can have a value of null.
if rel_field.null:
def remove(self, *objs):
val = getattr(instance,
rel_field.rel.get_related_field().attname)
for obj in objs:
# Is obj actually part of this descriptor set?
if getattr(obj, rel_field.attname) == val:
setattr(obj, rel_field.name, None)
obj.save()
else:
raise rel_field.rel.to.DoesNotExist, "%r
is not related to %r." % (obj, instance)
remove.alters_data = True
def clear(self):
for obj in self.all():
setattr(obj, rel_field.name, None)
obj.save()
clear.alters_data = True
#...
It looks to me like allowing null=True on ForeignKeys is therefore not
merely an oversight, which presumably means it gets sorted out
correctly at the backend. I think for now I may stick with null=True
and ask on django-developers.
Any thoughts?
Richard
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
