On Wednesday 09 December 2015 06:07:38 martin f krafft wrote:
> also sprach Shai Berger <s...@platonix.com> [2015-12-09 01:20 +0100]:
> > class Parent(Model):
> > content_type = ForeignKey('ContentType')
> >
> > class Child(Model):
> > parent = ForeignKey(Parent)
> > object_id = IntegerField()
> > # The next does not exist and they want it
> > egfk = ExtendedGenericForeignKey('parent__content_type', 'object_id')
>
> Precisely.
>
> > I suspect that this is a little too baroque for django core, and
> > further, it should be possible to implement in user code. Note
> > that GenericForeignKey itself is not part of Django core, but
> > a contrib app;
>
> Yes, and as noted in my initial mail: I wasn't even sure if turning
> to this list was the right thing to do.
>
> > there should be no reason why you cannot do what it does (with the
> > only possible exception being admin support).
>
> Yes, I have it all implemented, but it just seems like I am hacking
> and duplicating code and it feels aweful. Thus my itch to make the
> upstream code more flexible.
>
As far as I can see, you are trying to implement it in the model, rather than
as a new kind of field. Try to write ExtendedGenericForeignKey, and I think
things would look much better...
> > If you try to do that and find that you are missing something, or
> > need to use undocumented, private APIs, you'll have a very strong
> > case for having those problems solved.
>
> Isn't this enough:
>
>
> https://github.com/django/django/blob/stable/1.9.x/django/contrib/contentt
> ypes/fields.py#L151
>
... e.g. you'd be able to override this method.
HTH,
Shai.
