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 *WHER
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
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 wrote:
> On Tuesday, August 4, 2015, Shai Berger wrote:
>>
>> The classic database aggregation examples involve
On Tuesday, August 4, 2015, Shai Berger 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
Hi,
On Tuesday 04 August 2015 03:28:03 Josh Smeaton wrote:
> On Tuesday, 4 August 2015 07:10:05 UTC+10, Shai Berger wrote:
> > On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote:
> > > You can annotate raw SQL with expressions. I think the only case that
> > > can't be done with expressions
On Tue, Aug 4, 2015 at 8:06 AM, Tai Lee wrote:
> I think that while `extra()` gets a bad rap, it is extremely useful when
> creating generic pluggable apps, and I for one would miss it if it were to
> be removed.
The idea is that expressions should do everything that extra() can do.
There might b
I think that while `extra()` gets a bad rap, it is extremely useful when
creating generic pluggable apps, and I for one would miss it if it were to
be removed.
In a comment on #7231 a few years ago I wrote:
I can't reply to the discussion linked on Google Groups anymore, but wanted
> to add my
Can you explain/give an example of grouping over non relations? I'll see if
I can translate that to expressions in their current form.
On Tuesday, 4 August 2015 07:10:05 UTC+10, Shai Berger wrote:
>
> On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote:
> > You can annotate raw SQL with ex
On Monday 03 August 2015 10:27:14 Anssi Kääriäinen wrote:
> You can annotate raw SQL with expressions. I think the only case that can't
> be done with expressions is addition of extra tables to the query.
Also grouping over non-relations, if I am not mistaken.
Shai.
Thanks! Here's a polished version of that:
https://github.com/django/django/pull/5095
Let me know if it makes sense.
On Monday, August 3, 2015 at 9:10:00 AM UTC-4, Anssi Kääriäinen wrote:
>
> On Mon, Aug 3, 2015 at 2:07 PM, Tim Graham > wrote:
> > Is there an example we could give in the docs
On Mon, Aug 3, 2015 at 2:07 PM, Tim Graham wrote:
> Is there an example we could give in the docs to point readers in that
> direction?
There doesn't seem to be direct documentation about RawSQL expression.
The RawSQL is once mentioned in the documentionation, but it
definitely needs a bit more i
Is there an example we could give in the docs to point readers in that
direction?
On Monday, August 3, 2015 at 3:27:14 AM UTC-4, Anssi Kääriäinen wrote:
>
> You can annotate raw SQL with expressions. I think the only case that
> can't be done with expressions is addition of extra tables to the q
+1
- Anssi
On Friday, July 31, 2015 at 11:00:01 PM UTC+3, Tim Graham wrote:
>
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using
You can annotate raw SQL with expressions. I think the only case that can't
be done with expressions is addition of extra tables to the query. I am
certain we will get a solution to this too in future releases.
- Anssi
On Friday, July 31, 2015 at 9:01:45 PM UTC+3, Andres Osinski wrote:
>
> Wou
As some one who has had to abuse .extra() at times to make mssql things
work, I support this approach.
On Fri, Jul 31, 2015 at 4:00 PM, Tim Graham wrote:
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some
+1.
On Jul 31, 2015, at 2:12 PM, Marc Tamlyn wrote:
> Sounds good to me.
>
> On 31 July 2015 at 21:00, Tim Graham wrote:
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
>
> This is an old API that we aim to deprecate at some point in the future. Use
Sounds good to me.
On 31 July 2015 at 21:00, Tim Graham wrote:
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some point in the future.
> Use it only if you cannot express your query using other queryset m
I had in mind a documentation note like this:
Use this method as a last resort
This is an old API that we aim to deprecate at some point in the future.
Use it only if you cannot express your query using other queryset methods.
If you do need to use it, please file a ticket with your use case s
I wonder if there's a way in the docs we can deprecate it as in "we don't
recommend you use it", but not actually schedule it for removal.
On Friday, July 31, 2015 at 2:01:20 PM UTC-4, Marc Tamlyn wrote:
>
> I don't know about unmaintained, but I think there's a consensus that
> .extra() has a h
Would the expressions API be able to define fields that are aggregations of
complex foreign relationships? I keep using it when I need fields that are
the result of weird aggregations over multiple JOINs with some unusual
stuff like CASE fields and subqueries.
On Fri, Jul 31, 2015 at 2:58 PM, Tim
I don't know about unmaintained, but I think there's a consensus that
.extra() has a horrible API and we should do away with it eventually. That
said I think there are still enough things that can't be done without it at
present. A lot fewer now we have expressions, but still some.
I'd be happy to
In light of the new expressions API, the idea of deprecating
QuerySet.extra() has been informally discussed in IRC and elsewhere. I
wonder if there is consensus to mark extra() as "unmaintained" and to
suggest filing feature requests for functionality that can be performed
through extra() but n
22 matches
Mail list logo
