#28315: Support an API for filtering of GenericForeignKeys
-------------------------------------+-------------------------------------
Reporter: Michał Pasternak | Owner: nobody
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
-------------------------------------+-------------------------------------
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>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.6a4b69b37be2e73a4e8f2a2aac8acc37%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
