Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-31 Thread Shai Berger
On Wednesday 30 December 2015 08:40:17 martin f krafft wrote: > 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

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-29 Thread martin f krafft
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

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-10 Thread Florian Apolloner
On Wednesday, December 9, 2015 at 5:01:32 AM UTC+1, martin f krafft wrote: > > 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? > Just put the

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-09 Thread Shai Berger
On Wednesday 09 December 2015 06:07:38 martin f krafft wrote: > 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 =

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread martin f krafft
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 >

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread martin f. krafft
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

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread martin f. krafft
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:

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread Shai Berger
On Tuesday 08 December 2015 23:38:26 Tim Graham wrote: > I'm having trouble understanding the problem. Could you give some example > models and code that demonstrates it? > If I get things right: class Parent(Model): content_type = ForeignKey('ContentType') class Child(Model):

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread Florian Apolloner
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

Re: GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread Tim Graham
I'm having trouble understanding the problem. Could you give some example models and code that demonstrates it? On Tuesday, December 8, 2015 at 8:10:51 AM UTC-5, martin f krafft wrote: > > Hello, > > I hope this is the right place to bring up the following idea, even > if it's in

GenericForeignKey: loosening the requirements on the ContentType reference

2015-12-08 Thread martin f krafft
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