Re: future of QuerySet.extra()?

2015-08-21 Thread Adam Johnson 
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  wrote:
>>
>>> 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) 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
>>>  
>>> 
>>> .
>>> 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.

Re: future of QuerySet.extra()?

2015-08-06 Thread Adam Johnson 
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  > wrote:
>
>> 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) 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
>>  
>> 
>> .
>> 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/15f6552c-992f-4073-9802-0613ca498777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-04 Thread Josh Smeaton 
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 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-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/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com
> 
> .
> 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/CAPbDM0dLTZTBzZUcPPTY_4S9BympXtkm%3D%3DsNr1pZNYDxeauzMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-04 Thread Anssi Kääriäinen 
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) 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 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/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-04 Thread Shai Berger 
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 is addition of extra tables to the query.
> > 
> > Also grouping over non-relations, if I am not mistaken.
> > 
> 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.
> 
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.

There are many similar examples involving "enum columns" -- columns with a 
limited set of choices, where the choices are not instances of another model.

As far as I am aware, we can still not do these aggregates in the ORM,

Shai.

Re: future of QuerySet.extra()?

2015-08-04 Thread Anssi Kääriäinen 
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 be cases where this is not yet true, but I hope we will
get there in a couple of releases.

The extra() method should not  be better than expressions for reusable
apps. Actually the contrary, with expressions you can generate
different SQL for different databases.

> 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 comment that I have found many uses for .extra() and also
>> hit the limitation of being unable to add left outer joins to a query
>> generated by the ORM. I would not like to see it disappear in favour of raw
>> SQL.
>>
>>
>> My current use case is for joining reverse generic relations on queries
>> against a model that does not have a GenericRelation field back to the
>> generic model (because I don't know which models it will be used with -- I
>> can't add models to 3rd party code).
>>
>>
>> To require the whole query in raw SQL in order to join generic relations
>> would mitigate the pluggability of the generic model in question.
>
>
> While `raw()` may be allow you to get model instances from any custom SQL,
> it will often be prohibitively complicated or impossible to provide generic
> queryset methods that extend 3rd party apps. The RawSQL expression example
> given would appear to execute a subquery for each row of the result set. It
> wouldn't seem to help with the example above, unless I'm missing something?

What we want is something like
qs.add_relation(new_rel=Relation(SomeModel, on_clause=some_expression,
allow_nulls=True))

The some_expression variable generates sql for the ON clause, and
allow_nulls=True means the join will be LEFT join. Typically
some_expression could be something like Q(id=F('new_rel__other_id')) &
Q(new_rel__lang='fi').

The effect of this would be that the qs has a new relation called
new_rel to SomeModel, and that relation could be used in other query
constructs (for example .filter(new_rel__somef__lte=10)).

Making this work is high priority to me.

 - Anssi

-- 
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/CALMtK1GQ1oAgeSCgNvNu%3D1ucKEuduDOttpwCUCxSd-Ct8auzcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Tai Lee 
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 comment that I have found many uses for .extra() and also hit the 
> limitation of being unable to add left outer joins to a query generated by 
> the ORM. I would not like to see it disappear in favour of raw SQL.
>

> My current use case is for joining reverse generic relations on queries 
> against a model that does not have a GenericRelation field back to the 
> generic model (because I don't know which models it will be used with -- I 
> can't add models to 3rd party code).
>

> To require the whole query in raw SQL in order to join generic relations 
> would mitigate the pluggability of the generic model in question.


While `raw()` may be allow you to get model instances from any custom SQL, 
it will often be prohibitively complicated or impossible to provide generic 
queryset methods that extend 3rd party apps. The RawSQL expression example 
given would appear to execute a subquery for each row of the result set. It 
wouldn't seem to help with the example above, unless I'm missing something?

Cheers.
Tai.


On Monday, August 3, 2015 at 5:27:14 PM UTC+10, 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. 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:
>>
>> 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 Graham  wrote:
>>
>>> 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 not through other existing QuerySet methods? There are 
>>> at least several tickets (examples below) of edge cases that don't work 
>>> with extra(). It seems like a waste of time to leave these tickets as 
>>> accepted and to triage new issues with extra() if they won't be fixed.
>>>
>>> https://code.djangoproject.com/ticket/24142
>>> https://code.djangoproject.com/ticket/19434
>>> https://code.djangoproject.com/ticket/12890
>>>
>>> -- 
>>> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Andrés Osinski
>>
>

-- 
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/0613b9fc-358d-4aec-99e3-cec2d4fe9894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Josh Smeaton 
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 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. 
>

-- 
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/ef6cd23b-ea22-4cb2-b6f6-ad979a3f2aca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Shai Berger 
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.

Re: future of QuerySet.extra()?

2015-08-03 Thread Tim Graham 
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 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 in the database functions documentation. 
>
> The usage of RawSQL is really simple: 
> qs.annotate(val=RawSQL("(select col from sometable where othercol 
> = %s)", (someparam,))) 
>
> This is equivalent to qs.extra(select={'val': "select col from 
> sometable where othercol = %s"}, select_params=(someparam,)) 
>
> The main benefit of using RawSQL is that you can set output_field if 
> needed. The main downside is that if you refer to some table alias of 
> the qs in the raw sql, then it is possible that Django changes that 
> alias (for example, when the qs is used as a subquery in yet another 
> query). 
>
> Combining raw SQL with alias relabeling support is possible, too with 
> the following library: https://github.com/akaariai/django-refsql 
>
>  - Anssi 
>

-- 
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/70c66320-4af4-41ee-9df7-18facd3b82b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Anssi Kääriäinen 
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 in the database functions documentation.

The usage of RawSQL is really simple:
qs.annotate(val=RawSQL("(select col from sometable where othercol
= %s)", (someparam,)))

This is equivalent to qs.extra(select={'val': "select col from
sometable where othercol = %s"}, select_params=(someparam,))

The main benefit of using RawSQL is that you can set output_field if
needed. The main downside is that if you refer to some table alias of
the qs in the raw sql, then it is possible that Django changes that
alias (for example, when the qs is used as a subquery in yet another
query).

Combining raw SQL with alias relabeling support is possible, too with
the following library: https://github.com/akaariai/django-refsql

 - Anssi

-- 
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/CALMtK1G0xtEd7v-s60X-%3D2Ppwn7xS0NEmD_cWh8_0G2RT063mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Tim Graham 
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 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:
>>
>> 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 Graham  wrote:
>>
>>> 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 not through other existing QuerySet methods? There are 
>>> at least several tickets (examples below) of edge cases that don't work 
>>> with extra(). It seems like a waste of time to leave these tickets as 
>>> accepted and to triage new issues with extra() if they won't be fixed.
>>>
>>> https://code.djangoproject.com/ticket/24142
>>> https://code.djangoproject.com/ticket/19434
>>> https://code.djangoproject.com/ticket/12890
>>>
>>> -- 
>>> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Andrés Osinski
>>
>

-- 
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/17fae8b6-6d85-487d-b6e2-63c9cd735a02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Anssi Kääriäinen 
+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 other queryset methods. 
> If you do need to use it, please file a ticket with your use case so that 
> we can enhance the QuerySet API to allow removing extra(). We are no 
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> 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 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 put a moratorium on improving it, but we can't deprecate 
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
 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 not through other existing QuerySet methods? There are 
 at least several tickets (examples below) of edge cases that don't work 
 with extra(). It seems like a waste of time to leave these tickets as 
 accepted and to triage new issues with extra() if they won't be fixed.

 https://code.djangoproject.com/ticket/24142
 https://code.djangoproject.com/ticket/19434
 https://code.djangoproject.com/ticket/12890

 -- 
 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
  
 
 .
 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/3d1f957c-318b-4a28-8158-442f2e6cbb55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-08-03 Thread Anssi Kääriäinen 
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:
>
> 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 Graham  > wrote:
>
>> 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 not through other existing QuerySet methods? There are 
>> at least several tickets (examples below) of edge cases that don't work 
>> with extra(). It seems like a waste of time to leave these tickets as 
>> accepted and to triage new issues with extra() if they won't be fixed.
>>
>> https://code.djangoproject.com/ticket/24142
>> https://code.djangoproject.com/ticket/19434
>> https://code.djangoproject.com/ticket/12890
>>
>> -- 
>> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Andrés Osinski
>

-- 
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/1c66bb8d-ee9b-4215-aec8-1e63c844%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Michael Manfre 
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 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 so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> 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 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 put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
 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 not through other existing QuerySet methods? There are
 at least several tickets (examples below) of edge cases that don't work
 with extra(). It seems like a waste of time to leave these tickets as
 accepted and to triage new issues with extra() if they won't be fixed.

 https://code.djangoproject.com/ticket/24142
 https://code.djangoproject.com/ticket/19434
 https://code.djangoproject.com/ticket/12890

 --
 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
 
 .
 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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBsaOfA1gv5B4a6ZNs2NnZR1LUB0qZ-3b8ygh7n7TKTzug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Christophe Pettus 
+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 
> 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 so that we can 
> enhance the QuerySet API to allow removing extra(). We are no longer 
> improving or fixing bugs for this method.
> 
> 
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
> 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 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 put a moratorium on improving it, but we can't deprecate it 
> yet.
> 
> On 31 July 2015 at 18:58, Tim Graham  wrote:
> 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 not 
> through other existing QuerySet methods? There are at least several tickets 
> (examples below) of edge cases that don't work with extra(). It seems like a 
> waste of time to leave these tickets as accepted and to triage new issues 
> with extra() if they won't be fixed.
> 
> https://code.djangoproject.com/ticket/24142
> https://code.djangoproject.com/ticket/19434
> https://code.djangoproject.com/ticket/12890
> 
> -- 
> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com.
> 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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com.
> 
> 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/CAMwjO1FQAJqrXu3HcSpP3xDF%2BA%3DsyG%3DHP90V%3DzrKBHJ%3Dg%3DcfDg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

--
-- Christophe Pettus
   x...@thebuild.com

-- 
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/F2C975E9-D7A1-44BC-BD2A-C05F61917B3C%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Marc Tamlyn 
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 methods.
> If you do need to use it, please file a ticket with your use case so that
> we can enhance the QuerySet API to allow removing extra(). We are no
> longer improving or fixing bugs for this method.
>
> On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>>
>> 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 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 put a moratorium on improving it, but we can't deprecate
>>> it yet.
>>>
>>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>>
 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 not through other existing QuerySet methods? There are
 at least several tickets (examples below) of edge cases that don't work
 with extra(). It seems like a waste of time to leave these tickets as
 accepted and to triage new issues with extra() if they won't be fixed.

 https://code.djangoproject.com/ticket/24142
 https://code.djangoproject.com/ticket/19434
 https://code.djangoproject.com/ticket/12890

 --
 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
 
 .
 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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com
> 
> .
>
> 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/CAMwjO1FQAJqrXu3HcSpP3xDF%2BA%3DsyG%3DHP90V%3DzrKBHJ%3Dg%3DcfDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Tim Graham 
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 so that 
we can enhance the QuerySet API to allow removing extra(). We are no longer 
improving or fixing bugs for this method.

On Friday, July 31, 2015 at 2:07:34 PM UTC-4, Collin Anderson wrote:
>
> 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 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 put a moratorium on improving it, but we can't deprecate 
>> it yet.
>>
>> On 31 July 2015 at 18:58, Tim Graham  wrote:
>>
>>> 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 not through other existing QuerySet methods? There are 
>>> at least several tickets (examples below) of edge cases that don't work 
>>> with extra(). It seems like a waste of time to leave these tickets as 
>>> accepted and to triage new issues with extra() if they won't be fixed.
>>>
>>> https://code.djangoproject.com/ticket/24142
>>> https://code.djangoproject.com/ticket/19434
>>> https://code.djangoproject.com/ticket/12890
>>>
>>> -- 
>>> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>>  
>>> 
>>> .
>>> 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/7c1568b6-f7f1-4aab-9263-af447e45af45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Collin Anderson 
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 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 put a moratorium on improving it, but we can't deprecate 
> it yet.
>
> On 31 July 2015 at 18:58, Tim Graham > 
> wrote:
>
>> 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 not through other existing QuerySet methods? There are 
>> at least several tickets (examples below) of edge cases that don't work 
>> with extra(). It seems like a waste of time to leave these tickets as 
>> accepted and to triage new issues with extra() if they won't be fixed.
>>
>> https://code.djangoproject.com/ticket/24142
>> https://code.djangoproject.com/ticket/19434
>> https://code.djangoproject.com/ticket/12890
>>
>> -- 
>> 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-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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
>>  
>> 
>> .
>> 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/3d575638-a365-4257-8f46-dcf65a69c03c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Andres Osinski 
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 Graham  wrote:

> 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 not through other existing QuerySet methods? There are
> at least several tickets (examples below) of edge cases that don't work
> with extra(). It seems like a waste of time to leave these tickets as
> accepted and to triage new issues with extra() if they won't be fixed.
>
> https://code.djangoproject.com/ticket/24142
> https://code.djangoproject.com/ticket/19434
> https://code.djangoproject.com/ticket/12890
>
> --
> 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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrés Osinski

-- 
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/CA%2BxF-PwnnPNyOOUzUHPaYG1mRQS7Fynys0o%3DoK9_g2ESTBRM2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

2015-07-31 Thread Marc Tamlyn 
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 put a moratorium on improving it, but we can't deprecate it
yet.

On 31 July 2015 at 18:58, Tim Graham  wrote:

> 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 not through other existing QuerySet methods? There are
> at least several tickets (examples below) of edge cases that don't work
> with extra(). It seems like a waste of time to leave these tickets as
> accepted and to triage new issues with extra() if they won't be fixed.
>
> https://code.djangoproject.com/ticket/24142
> https://code.djangoproject.com/ticket/19434
> https://code.djangoproject.com/ticket/12890
>
> --
> 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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com
> 
> .
> 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/CAMwjO1EL3TMnP%2BrtkKDMt1%3D8wwXpRV%2Btfn%3DRQA5tYC0bkQzMAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

future of QuerySet.extra()?

2015-07-31 Thread Tim Graham 
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 not through other existing QuerySet methods? There are 
at least several tickets (examples below) of edge cases that don't work 
with extra(). It seems like a waste of time to leave these tickets as 
accepted and to triage new issues with extra() if they won't be fixed.

https://code.djangoproject.com/ticket/24142
https://code.djangoproject.com/ticket/19434
https://code.djangoproject.com/ticket/12890

-- 
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/6e1be326-3b17-49ca-accf-03eec5ad41ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.