Re: Adding generated common table expressions

[Javier Buzzi]

What do you think of this syntax instead?

q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price'))
q2 = Author.objects.attach('book_prices', q1, id=F('book_prices__author_id'
))


def attach(name, queryset, **params):
   # Would look something like this.
   ...


Same sql output.

On Thursday, April 6, 2017 at 9:14:01 AM UTC-4, Anssi Kääriäinen wrote:
>
> On Thursday, April 6, 2017 at 11:53:32 AM UTC+3, Marc Tamlyn wrote:
>>
>> Regarding Anssi's comments about SubQuery, we do now have that in core as 
>> of 1.11 [0]. It does look like an .attach() approach might actually have 
>> been a nicer version of this, but on the other hand it's currently 
>> implementable solely with the Expressions API. It seems like the OuterRef 
>> is very similar to your queryset.ref(). An even nicer approach using attach 
>> could be to say qs.attach(q1=some_qs).filter(a=F('q1__b'))?
>>
>
> Hmmh, we have one form of SubQuery, but that's actually for SELECT clause, 
> not for FROM clause. I believe the same class won't work for the CTE or 
> subquery in FROM clause case.
>
> As for the attach(), seems like a really nice syntax. We do need something 
> for generating the join clause for the JOIN. If you look at an example:
> q1 = Book.objects.values('author_id').annotate(avg_price=Avg('price'))
> q2 = Author.objects.attach(q1=q1)
> it needs to create something like:
> WITH q1 AS (
> SELECT author_id, avg(price) FROM book GROUP BY author_id
> )
> SELECT author.id, author.name
>FROM author
>LEFT JOIN q1 ON author.id = q1.author_id;
>
> Or, equivalently without the CTE:
>
> SELECT author.id, author.name
>FROM author
>LEFT JOIN ( SELECT author_id, avg(price) FROM book GROUP BY author_id) 
> ON author.id = q1.author_id;
>
> Now, the main points are:
>1. There is no need to design this to be about CTEs. That just limits 
> the feature from backends that don't have CTEs without any real benefit. 
> From Django's perspective the two above queries are the same.
>2. We do need something for the JOIN ON condition. In some cases Django 
> could guess this, but there needs to be an explicit way to express the join 
> condition.
>
> If we allow usage of expressions from the attached queryset, but don't try 
> to go for cases where model instance are created from the attached 
> queryset, this will be both possible to implement without having to write a 
> change-everything patch, and this will also be a really nice feature.
>
> For recursive CTEs, I'd leave that strictly as a later step. The only 
> thing we need to check right now is that we don't do something that 
> prevents a good recursive CTEs implementation later on.
>
>  - Anssi
>
>>
>> Looking forwards to seeing a DEP!
>>
>> [0] 
>> https://docs.djangoproject.com/en/1.11/ref/models/expressions/#subquery-expressions
>>
>> On 22 March 2017 at 01:32, Ashley Waite  wrote:
>>
>>> Here's the code changes I've made, noting that some of them were to 
>>> shove in a generalised VALUES clause that mocks being a queryset, so that 
>>> it plays with the same interface.
>>>
>>>
>>> https://github.com/django/django/compare/master...ashleywaite:cte-dev#files_bucket
>>>
>>> I've had a glance at cte-trees/cte-forest and once general CTEs are 
>>> worked out expanding that to include recursive CTEs wouldn't be too 
>>> difficult, and that would greatly simplify the implementation of cte-forest 
>>> to the extent that it might be viable as a django data/reference type.
>>>
>>> - Ashley
>>>
>>>
>>> On Saturday, March 18, 2017 at 8:28:53 PM UTC+11, Josh Smeaton wrote:

 Thanks for bringing this up Ashley, and for all of the detail you 
 provided. I'd certainly like to see CTEs make their way into Django, 
 provided we could come up with a nice enough API. From the look of it, 
 you've already got something that works with an okay API so I'm hopeful.

 I'd be very interested in seeing your POC too if you're able to share.

 From looking very briefly at django-cte-trees it doesn't aim to support 
 user defined CTEs for anything other than recursive queries. I'd be 
 interested in seeing, as part of a DEP, how CTE inclusion in django core 
 could support the cte-trees project from an API perspective.

 On Friday, 17 March 2017 22:28:17 UTC+11, Ashley Waite wrote:
>
> Hey all,
>
>
> I'd like to suggest adding Common Table Expression (CTE) query 
> generation as a feature to Django.
>
> I've been working on a project that required manipulation of many 
> records at once, and as with many ORMs found that this wasn't an ideal 
> use-case in Django. As the rest of our code base and related projects are 
> in Django, there was a strong preference to find a way to do it and keep 
> to 
> the same model-is-the-truth design.
>
> I first did this by writing some hackish functions using raw querysets 
> and generating my own CTE based queries, but 

Re: #30864 Document and endorse django.utils.decorators.classproperty

[keshav kumar]

Hi Adam,

Thanks for your answer. I want to contribute to django, I have read many 
issues but still I am not getting how to work on it and what it wants  from 
me to do. Can you suggest me only one ticket on which I can work. so that I 
can understand how the whole thing works.

On Friday, 18 October 2019 02:17:11 UTC+5:30, keshav kumar wrote:
>
> I want to work on this ticket. Can you tell me how can I proceed for it?
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/73e6e6f9-211f-4e0a-a69a-bb95b4e90a51%40googlegroups.com.

Re: #30864 Document and endorse django.utils.decorators.classproperty

[Adam Johnson]

Hi Keshav,

Thanks for volunteering. The most recent comment says #30876 should be done
first - maybe try do that?

This guide shows you how to get started editing the documentation:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-documentation/

This guide, and some linked guides, show you how to make a pull request
from your changes:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/

Here's an example PR I did recently that similarly changes the
documentation: https://github.com/django/django/pull/11814

I hope that's enough reference to get started!

Adam

On Thu, 17 Oct 2019 at 21:47, keshav kumar  wrote:

> I want to work on this ticket. Can you tell me how can I proceed for it?
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/26e29390-e452-41af-8a8a-cb7e0ad858f7%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2zXeOnGSJjRvm5pFYML8MTZ8rrFppNruaahHMqLkZSkA%40mail.gmail.com.

#30864 Document and endorse django.utils.decorators.classproperty

[keshav kumar]

I want to work on this ticket. Can you tell me how can I proceed for it?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/26e29390-e452-41af-8a8a-cb7e0ad858f7%40googlegroups.com.

Re: Question about PR for #27391 -- Implement SimpleTestCase.debug method

[Pavel Savchenko]

Thanks will do!

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2ab045aa-6eed-4d8f-80d8-6afba2a3fe7e%40googlegroups.com.

Re: Question about PR for #27391 -- Implement SimpleTestCase.debug method

[Mariusz Felisiak]

Hi Pavel,

   Thanks for this PR. You don't need to do anything at the moment, just be 
patient, it's waiting in a review queue and it's on my list.

Best,
Mariusz

W dniu środa, 16 października 2019 14:26:19 UTC+2 użytkownik Pavel 
Savchenko napisał:
>
> Hello, 
>
> Is there anything left to-do or discuss to finish this? 
>
> https://github.com/django/django/pull/7436 
> 
>  
>
>
> Regards, 
> Pavel

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/910ab72f-0758-4b90-957c-7bf1b0d96b80%40googlegroups.com.