[Django] #28315: Support an API for filtering of GenericForeignKeys
Django
-------------------------------------+-------------------------------------
Reporter: Michał | Owner: nobody
Pasternak |
Type: New | Status: new
feature |
Component: Database | Version: 1.11
layer (models, ORM) | Keywords: generic foreign
Severity: Normal | keys content types filtering
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Hi,
just to let you know, my project that allows filtering of
GenericForeignKeys called "djorm-ext-filtered-contenttypes" supports
Django versions 1.8-1.11 on Python 2.7, 3.5 and 3.6.
{{{#!python
class Foo(models.Model):
a = GenericForeignKey()
Foo.objects.filter(a__in=[ThisModel, OtherModel, AnotherModel])
}}}
My package relies on PostgreSQL and allows to efficiently filter
GenericForeignKeys using server-side SQL which looks like:
{{{#!python
SELECT ... FROM ... WHERE (t0.content_type_id, t0.object_id) IN (....)
}}}
If you add a compound index on t0(content_type_id, object_id)... speed and
efficiency.
Check it out: https://github.com/mpasternak/djorm-ext-filtered-
contenttypes . If there is any interest from core developers, I'm willing
to submit a high-quality patch to the main branch, probably living
somewhere below contrib.postgresql
--
Ticket URL: <https://code.djangoproject.com/ticket/28315>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution: duplicate
Keywords: generic foreign | Triage Stage:
keys content types filtering | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* has_patch: 1 => 0
* resolution: => duplicate
Comment:
Duplicate of #23046. Hi again, three years later. ;-)
Perhaps you can raise the idea on the DevelopersMailingList to get some
other feedback. I think many developers avoid `GenericForeignKey` in the
first place so I'm not if enhancing the functionality is a big priority. I
noticed several "this is a hack" comments in your project. I would say you
should either try to clean those up before moving forward, or explain how
inclusion in Django will allow removing the hacks.
--
Ticket URL: <https://code.djangoproject.com/ticket/28315#comment:1>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 1.11
(models, ORM) |
Severity: Normal | Resolution: duplicate
Keywords: generic foreign | Triage Stage:
keys content types filtering | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Michał Pasternak):
Hey, yes, I'm back.
I second your opinion. Me myself, I haven't really decided between "I wish
I have never used GenericForeignKeys" and "this is cool functionality and
PostgreSQL makes it even better". But... if your opinion on this topic
reflects the general opinion of the whole Django core team - IDK, maybe it
would be better to move GenericForeignKeys to external module and rip them
out of Django... or to add some more stuff, likewise as PostgreSQL
contrib. Having them in makes the ORM less database-y and more NoSQL...
... but if you look at how are things implemented, they're a terrible
hack. Like a bomb waiting to blow up someday.
Anyways, as for me and my small project, I'm glad to be on your radar,
just in case.
--
Ticket URL: <https://code.djangoproject.com/ticket/28315#comment:2>