Actually I spoke too soon, I excitedly misunderstood what *RawSQL* does/doesn't
do. Unfortunately it requires access to a column, which is not what I need.
I'm inserting WHERE conditions like */*specialcomment*/1* - the special
comment is translated into query rewriting, leaving *1* in the *WHERE*
condition
as a no-op. Unfortunately I can't see a way of injecting the raw SQL into
the *QuerySet* using *filter* without referring to a column (required to
make the ORM extension work without affecting queries too badly) - so
*extra* remains the only solution here, unless I'm missing something... any
suggestions welcome
( https://github.com/adamchainz/django-mysql/pull/144/files ).
On Thursday, August 6, 2015 at 10:06:38 PM UTC+1, Adam Johnson wrote:
>
> I've seen *extra()* misused in cases where developers came from a
> background of writing raw SQL and then used it rather than figuring out the
> (often relatively simple) ORM way of doing it. This is then a big
> maintenance burden, and the harsher warning against its use is a good idea.
>
> Also thanks for documenting *RawSQL*, didn't realize it was usable until
> now so I've been able to get rid of some *extra()* usage in django-mysql.
>
> On Wednesday, August 5, 2015 at 1:09:30 AM UTC+1, Josh Smeaton wrote:
>>
>> You're right about that. You can aggregate over custom expressions. For
>> aggregating over enums you should be able to use case expressions
>>
>> On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen <akaa...@gmail.com> wrote:
>>
>>> On Tuesday, August 4, 2015, Shai Berger <sh...@platonix.com> wrote:
>>>>
>>>> The classic database aggregation examples involve aggregation over
>>>> time: Sum
>>>> of sales per quarter (which is, itself, a function over date); average
>>>> temparature per month; etc. All these require group-by clauses which
>>>> name
>>>> (expressions over) columns which are not FKs.
>>>>
>>>>
>>> The following should work:
>>>
>>>
>>>
>>> qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))
>>>
>>> I recall some changes to how the group by expression is generated for
>>> expressions. If I recall correctly the group by should have the expression
>>> itself now, not the base columns of the expression.
>>>
>>> There are many similar examples involving "enum columns" -- columns with
>>>> a
>>>> limited set of choices, where the choices are not instances of another
>>>> model.
>>>
>>>
>>> I'm not sure of this one.
>>>
>>> - Anssi
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/django-developers/FojuU0syO8Y/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> 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/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/3521e31f-48a9-4576-86aa-b13227a7c29c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
