Hmmm, now the question is, is that intended for databases that can handle
a temporary null in a foreign key? What DB are you using? I see that
Postgres gives me no grief about null=True, since it sets up as
CREATE TABLE licensing_server
(
id int4 NOT NULL DEFAULT nextval('licensing_server_id_seq'::regclass),
name varchar(200) NOT NULL,
revised_date timestamptz NOT NULL,
current_ip inet NOT NULL,
mac_address varchar(22) NOT NULL,
current_hostname varchar(100) NOT NULL,
platform varchar(60) NOT NULL,
tier int4 NOT NULL,
area_of_application varchar(60) NOT NULL,
role varchar(11) NOT NULL,
status varchar(11) NOT NULL,
server_twin_id int4 NOT NULL,
server_sibling_id int4 NOT NULL,
primary_fte_id int4 NOT NULL,
CONSTRAINT licensing_server_pkey PRIMARY KEY (id),
CONSTRAINT licensing_server_primary_fte_id_fkey FOREIGN KEY
(primary_fte_id) REFERENCES licensing_fte (id) ON UPDATE NO ACTION ON
DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,
CONSTRAINT server_sibling_id_refs_id_13bbfcb7 FOREIGN KEY
(server_sibling_id) REFERENCES licensing_server (id) ON UPDATE NO ACTION
ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,
CONSTRAINT server_twin_id_refs_id_13bbfcb7 FOREIGN KEY (server_twin_id)
REFERENCES licensing_server (id) ON UPDATE NO ACTION ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED
)
That one is complex--but look at the last 3 constraints. The Foreign Key
in the first constraint points to another table (licensing_fte) where an
id is expected. The last two constraints are Foreign Keys that point back
into the same table (adjacency list). I did NOT set null=True, but I can
load data until I change the CONSTRAINT ACTION. When I change the
constraint actions, I will get bitten by the DB as soon as I have a FK
that doesn't tie out.
>
>> 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 django-users@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
