GenericForeignKey fails if initialized to None during model init

[Sam Bull]

Supposing you have a model with a GenericForeignKey...

class Example(models.Model):
    name = models.CharField()
    content_type = models.ForeignKey(ContentType, null=True, blank=True)
    object_id = models.PositiveIntegerField(null=True, blank=True)
    obj = GenericForeignKey()

If you initialize like this, everything is fine:

ex = Example(name='foobar')

But if you do this...

ex = Example(name='foobar', obj=None)

You get an exciting error:
Impossible arguments to GFK.get_content_type!

It looks like the GFK tries to initialize the content_type and object_id fields if its attribute is one of the ones passed to the init. In fact, it should follow the example of get and only initialize those fields if the argument passed to it is non-None.

[Sam Bull]

GFK-init patch

[Sam Bull]

Gah, I realized my ct and obj_id fields in the example won't work with the GFK field unless I tell it what they're called. This is a bug in my example, my original code properly identifies the content type and object id fields to the GFK.

[James Bennett]

This feels like enough of an edge case (knowingly passing None when you could just leave it out of the argument list to the constructor) that it can wait a bit.

[Sam Bull]

revised patch

[Sam Bull]

I've tried to provide a better patch.

I agree that this is an unusual situation, but it can cause hard to debug errors. The problem is that you might be passing in an object via the model's constructor and not know if it's None or not.

Null GFK fields are allowed, so passing in a value that might be None should be allowed as well.

I do agree that this may not be needed for 1.0, but I wanted to highlight the problems this bug causes.

[(none)]

Milestone post-1.0 deleted

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Ramiro Morales]

See also #18599.

[Bouke Haarsma]

I've improved on this patch by also checking if None is allowed as the foreign key. Previous patches just ignored None, but that doesn't seem right as sometimes None is really invalid, for example when the GFK is non-optional. See my PR: ​https://github.com/django/django/pull/1753.

[Tim Graham <timograham@…>]

In 3918eeb9fde03a2ad1941bce022615fff8eae34d:

Fixed #7551 -- Made GFK allow None init argument.

Thanks SamBull for the report.