Re: future of QuerySet.extra()?

[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: Setting up Django Over Apache Web-server

[gilberto dos santos alves]

hi. if you have cpanel see [1] or another similiar shared host plan.

[1] http://support.hostgator.com/articles/django-with-fastcgi

2015-08-03 20:36 GMT-03:00 Mudassar Hashmi :

> Please help to upload django on apache web server with without terminal
> access to web server.
>
> Regards,
>
> Mudassar Hashmi
>
> --
> 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/COL126-W255BB734B46EC91F6C6D58C8770%40phx.gbl
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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/CAP9G-NL%3DGxW4Jw_zxYaUCCDJ1f8rPeJis%2BiDq84nBDR4Qnm01Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[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.

Setting up Django Over Apache Web-server

[Mudassar Hashmi]

Please help to upload django on apache web server with without terminal access 
to web server.
Regards,
Mudassar Hashmi   

-- 
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/COL126-W255BB734B46EC91F6C6D58C8770%40phx.gbl.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[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()?

[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: default values on database level

[Michael Manfre]

On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron 
wrote:
>
> >   - Do we want to allow extending this to defaults that are applied on
> every save (automatic database backed modified timestamps for example)?
>
> +1 for this one too.
>

This behavior would be a nice step toward computed (readonly) database
fields.



-- 
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/CAGdCwBv6yJX%2BdbOfFkqAq8ozBHsE5TkSH5ig9nzj%2Bvz%2BezRELg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: default values on database level

[Podrigal, Aron]

On Aug 3, 2015 3:36 AM, "Anssi Kääriäinen"  wrote:
>
> On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote:
>>
>> I would like to propose making Fields.default to rely on the database
generated defaults where possible. This could be implemented by having
some  constants like fields.CURRENT_TIMESTAMP, etc.  The tricky part here
is to detect database backend specific capabilities and have a python
equivalent fallback.
>>
>> Any thoughts?
>
>
> A couple of questions about this:
>   - What should happen when you instantiate a new model with DB default,
and show that model to the user in a form. Is the field shown to the user,
and if so, what value should it have?

The field would have no value, so when displayed on the form it would be
blank. A field with blank=False which is included in a form, having a
db_default would be useless.

>   - How to implement actual fetching of the values after save() -
PostgreSQL supports RETURNING, but this is not the case for all databases.

The value would be fetched on demand on its first access, saving a trip to
the database if the field is not accessed. Subsequent updates on that
instance would leave out that field from the list of fields to be updated,
unless its value has been changed on the instance. Maybe we can allow to
handle this based on some parameter provided to save() ?

>   - When is the default applied? On first save of the model, or on model
init time?

Of course on first save, as we want the default value atomically within the
same transaction.

>   - Do we want to allow extending this to defaults that are applied on
every save (automatic database backed modified timestamps for example)?

+1 for this one too.

>
>  - 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/f1a7cc68-de1a-49f8-bdf8-ebfaade59955%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/CANJp-yhtS4xVy4MLoOs%2B0%2B_9AnkZqmpw%2BVmG8pO%3DQ%2Byda01yAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[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: Field.get_flatchoices seems to never get used

[Tim Graham]

Fixed in https://github.com/django/django/pull/5093, thanks for the report.

On Sunday, August 2, 2015 at 12:48:13 PM UTC-4, Collin Anderson wrote:
>
> That looks right to me.
>
> On Sun, Aug 2, 2015 at 11:51 AM, Andy Baker  > wrote:
>
>> I'll file a ticket but I wanted a quick sanity check first.
>>
>> In db.models.fields.Field there is a method called get_flatchoices (as 
>> well as _get_flatchoices which is turned into a property).
>>
>> I've searched the source for 'get_flatchoices' and it's never called. 
>> There doesn't appear to be any mention of it except in a few ancient 
>> tickets.
>>
>> -- 
>> 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/6ba31eda-8f84-490a-8dce-0448452c9510%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/22fef6d6-3501-481f-b286-504e6a5663b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[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: default values on database level

[Anssi Kääriäinen]

On Wednesday, July 29, 2015 at 8:05:10 AM UTC+3, Aron Podrigal wrote:
>
> I would like to propose making Fields.default to rely on the database 
> generated defaults where possible. This could be implemented by having 
> some  constants like fields.CURRENT_TIMESTAMP, etc.  The tricky part here 
> is to detect database backend specific capabilities and have a python 
> equivalent fallback.
>
> Any thoughts?
>

A couple of questions about this:
  - What should happen when you instantiate a new model with DB default, 
and show that model to the user in a form. Is the field shown to the user, 
and if so, what value should it have?
  - How to implement actual fetching of the values after save() - 
PostgreSQL supports RETURNING, but this is not the case for all databases.
  - When is the default applied? On first save of the model, or on model 
init time?
  - Do we want to allow extending this to defaults that are applied on 
every save (automatic database backed modified timestamps for example)?

 - 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/f1a7cc68-de1a-49f8-bdf8-ebfaade59955%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[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()?

[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.