also sprach Shai Berger [2015-12-10 08:38 +1300]:
> 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...
Hi, thanks for your response and sorry for taking su
also sprach Shai Berger [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 = ExtendedGeneri
also sprach Florian Apolloner [2015-12-08 23:38 +0100]:
> but if it were for me GFK would have a special case in hell.
How would you implement LogEntries without GFKs?
--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
"as if you could kill time without injuring eternity."
also sprach Tim Graham [2015-12-08 22:38 +0100]:
> I'm having trouble understanding the problem. Could you give some example
> models and code that demonstrates it?
Gladly. The code I am talking about is here:
https://github.com/madduck/wafer/blob/147-kvpairs/wafer/kvpairs/models.py
https:/
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
