generic relations do not act as expected in a filter/get

[jeroen_at_lbvd.nl]

If I have a model like this:

class SecurityContext(models.Model):
    title = models.CharField(maxlength=100)
    description = models.TextField()

class AccessList(models.Model):
    principal_id = models.PositiveIntegerField()
    principal_ct = models.ForeignKey(ContentType)

    security_context = models.ForeignKey(SecurityContext)
    principal = models.GenericForeignKey(fk_field="principal_id", ct_field="principal_ct")
    permission = models.ForeignKey(Permission)
    class Admin:
        pass

class MyModel(models.Model):
    security_context = models.ForeignKey(SecurityContext)
    owner = models.ForeignKey(User)

    my_field = models.CharField(maxlength=50)

    class Admin:
        pass

Then I expect to be able to do something like:

my_model_instance.security_context.accesslist_set.filter(principal=user_object)

and have it return a list of all accesslist entries for the given principal (similar to ForeignKeys or M2M relations).
Instead I get an error stating: Cannot resolve keyword 'principal' into field.

The following does work however:

my_model_instance.security_context.accesslist_set.filter(principal_id=user_object.id)

[anonymous]

If nothing can be done to fix this, the fact that it cannot be done should at least be documented.

[mrts]

In scope for 1.0.

[Robert Myers]

I believe this functionality will not be easy to create. Basically a generic foreign key is not a field, so it can not be used in a the ORM like normal fields. It would need to be coverted to a field subclass and all the methods that work with the db will need to be overridden. I question whether it would be a good idea to make this field overly complicated just to get this functionality.

[Robert Myers]

documentation patch added

[Malcolm Tredinnick]

It's probably possible to do this eventually, although it needs #5937 to be fixed first. Agree that it's fiddly, though. Marking for post-1.0. It's never been reasonable to expect this to work. We can make this someday/maybe in case somebody comes up with a good implementation in the future.

I'll drop in your docs patch in a moment to clarify things for 1.0. Thanks for doing the investigative work on this one.

[Malcolm Tredinnick]

(In [8417]) Documented that GenericForeignKey fields can't be used transparently in
filters. Refs #3006. Patch from rmyers.

[(none)]

Milestone post-1.0 deleted

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[coleifer]

I'd like to work up a patch to merge in some of the functionality i've written for dealing with GFKs -- including filter, annotate and aggregate:

​https://github.com/coleifer/django-generic-aggregation/blob/master/generic_aggregation/utils.py

[Asif Saifuddin Auvi]

Replying to coleifer:

I'd like to work up a patch to merge in some of the functionality i've written for dealing with GFKs -- including filter, annotate and aggregate:

​https://github.com/coleifer/django-generic-aggregation/blob/master/generic_aggregation/utils.py

go for it if you are still interested!!!

[Karolis Ryselis]

I have created a pull request for this at ​https://github.com/django/django/pull/9748. This special-cases generic relations when filters are added to query. It only works for simple lookups as nested lookups make no sense, i.e.,

TaggedItem.objects.filter(content_object=obj)

works and

TaggedItem.objects.filter(content_object__name="name")

will be caught by the old checks

[Asif Saifuddin Auvi]

can we conditionally accept this to move forward?

[Carlton Gibson]

Patch looks good. Not 100% sure it's needed given GenericRelation is already available.

[Tim Graham]

I'd lean toward a wontfix. In particular, making changes in django/db/models/sql/query.py for a contrib app doesn't look like a good separation of concerns. Is there a downside to the alternative of adding the GenericRelation?

[Tim Graham]

Feel free to continue the ​discussion on django-developers if there's some motivation for this.