In addition to what Tim already said, I think the acceptance of a patch on
such a feature would depend on the (quality of the) patch itself. I am not
going to spelk for the whole core team here, but I think most of the people
in the core team try to avoid generic FKs for plenty of reasons. As such a
change in this area might have better chances with an existing patch
showing what you are trying to achieve. I know, that this puts a lot of
pressure on you, or at least asks for work which might soon be forgotten --
but if it were for me GFK would have a special case in hell.
Cheers,
Florian
On Tuesday, December 8, 2015 at 2:10:51 PM UTC+1, martin f krafft wrote:
>
> Hello,
>
> I hope this is the right place to bring up the following idea, even
> if it's in django.contrib.contenttypes.
>
> GenericForeignKeys currently hard-require a model to have
> a ForeignKey field to the ContentType model. In a specific use-case,
> we're experiencing a bit of trouble with this, because the
> ContentType in our case is actually indirectly available via another
> ForeignKey:
>
> MyModel → n:1 → ParentModel → n:1 → ContentType
>
> However, contenttypes cannot be convinced to access the extra level
> of indirection and complains that MyModel.ForeignKey('ParentModel')
> is not a ForeignKey('ContentType').
>
> Despite the additional query overhead, it'd be great if instead
> I could tell contenttypes that it should
>
> either
> (a) look beyond the current model for the actual content_type
> attribute, e.g. content_type='myattribute.content_type',
> which, if myattribute is a ForeignKey itself adds a level of
> indirection but doesn't change the logic and causes
> contenttypes to resolve myattribute and use the content_type
> field on the result,
>
> or
> (b) avoid hard-coding the dependency on ContentType and instead
> duck-type the argument, such that my parent model could expose
> the necessary functionality, e.g. via proxy calls to the
> ForeignKey on ContentType stored in the parent.
>
> Does this make sense? Would it be worthwhile to start working on
> a patch for this? Which of (a) or (b) would be preferred? It feels
> to me that while (b) is the Pythonesque way, (a) is more Django…
>
> Looking forward to your thoughts,
>
> --
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/
>
> warning: dates in calendar are closer than they appear.
>
> spamtraps: [email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/1f36b7b5-4ec5-42fa-a6ba-d62f90cad9b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
