On Tuesday, December 8, 2015 at 5:28:08 PM UTC+2, Michael wrote:
>
> On Tuesday, December 8, 2015 at 1:26:52 AM UTC-6, Anssi Kääriäinen wrote:
>>
>>
>> Come to think of it, we already have a workaround:
>>Book.objects.annotate(author_cnt=RawSQL("(select count(*) from author
>> where author.boo
On Tuesday, December 8, 2015 at 2:52:07 PM UTC+2, Josh Smeaton wrote:
>
> Yeah I'm wary that a lot of the problems with extra() will be replicated
> by users switching to RawSQL() instead. It won't handle realiasing or group
> by correctly.
>
The group by case we can fix by creating a separate R
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:/
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):
p
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 su
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 django.contrib
On Tuesday, December 8, 2015 at 1:26:52 AM UTC-6, Anssi Kääriäinen wrote:
>
>
> Come to think of it, we already have a workaround:
>Book.objects.annotate(author_cnt=RawSQL("(select count(*) from author
> where author.book_id = book.book_id)").
>
Yes, you can do a subquery to get the Sum or Co
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
Yeah I'm wary that a lot of the problems with extra() will be replicated by
users switching to RawSQL() instead. It won't handle realiasing or group by
correctly.
On Tuesday, 8 December 2015 18:26:52 UTC+11, Anssi Kääriäinen wrote:
>
>
>
> On Tuesday, December 8, 2015 at 3:16:20 AM UTC+2, Michae
Hi Lennart,
I certainly like the idea and have written at least two implementations of
`ConfirmView` in my projects before. Without getting into specifics, I'm
not sure how we feel about adding more generic views like this, even where
it does make sense. To me a good initial course of action could
Hello,
I'm another Debian developer co-maintaining Django in Debian.
Le lundi 30 novembre 2015, Florian Apolloner a écrit :
> I am not against including it, but depending on how packaging works in
> Debian it could be possible to call pycompile with a proper exclusion list
> instead. The PR its
13 matches
Mail list logo
