Re: Custom template directory name in apps

['Adam Johnson' via Django developers (Contributions to Django itself)]

I agree with Mariusz.

Moreover, the app directories loader class is really small. You can create
a project-specific version in 3 lines, if you need:

class Loader(FilesystemLoader):
def get_dirs(self):
return get_app_template_dirs("email-templates")

On Tue, May 10, 2022 at 6:27 AM Mariusz Felisiak 
wrote:

> Hi,
>
> Thanks for the proposition. I'm not sure why the new option is better
> than using subdirectories in *"templates"  *e.g. *"templates/mail/".*
>
> Best,
> Mariusz
>
> --
> 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/fb7408c2-aa2d-4dfb-a624-a042a68e5b55n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0D4n_1yDrjxZ%3Dx7ZVzcnyMz3u7nSp1avGcamQdkz81HQ%40mail.gmail.com.

Status of 4.1 pre-release.

[Carlton Gibson]

Hi all. 

Time to begin release process for the next major release, Django 4.1!

It's been an incredible cycle with (again) a staggering number of 
contributions. Thank you everyone! 

The 4.1 feature freeze is scheduled (according to 
https://code.djangoproject.com/wiki/Version4.1Roadmap) for Tuesday May 17. 
I'd 
like to release the alpha that day, but it may be Wednesday or Thursday. 

There have been a number of changes improving the accessibility of the 
default
form rendering (tickets #32338 and #32229) for which there's a deprecation 
and
docs changes pending to round-off. 

We want to get as far as we can on that. It's being worked on here: 
https://github.com/django/django/pull/15665

We also have a couple of release blockers that we'd like to resolve this 
week 
so that we can release clean. 

Both Mariusz and I have a short-list of further tickets that have been
bubbling: we'll get as far as we can on those. We've both been head-down
working hard towards the feature freeze for a number of weeks. It's coming
together well, but all I can say is sorry if your particular ticket doesn't
make it this time. 

As per the roadmap, we have pre-releases through June and July, targeting 
August 3 for Django 4.1 final. 

Please test early and often. 

We will use this thread to inform you of any changes to the schedule. 

Thanks again. It wouldn't be possible without you! 🎁

Kind Regards,

Carlton

-- 
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/c0c5af4f-9870-4ea3-ae0d-bbdfa66af780n%40googlegroups.com.

Re: Adding generated common table expressions

[Gaga Ro]

Hello everyone,

I'm often using django-cte and I'd be thrilled to have CTE in the core.

If I'm not mistaken, the only DB currently supported by Django and not 
having CTE support is MySQL 5.7 (with an end of life in October 2023). I 
don't know if Django 4.2 will support it, but it should be dropped for 
Django 5.0 as it will be released in 2023. So we should have all supported 
DB supporting CTE when this feature would be over.

The ticket (https://code.djangoproject.com/ticket/28919) has been stalled 
for a few years now, this thread as well. I am willing to work on this but 
I would like more information first.

If I try to list all the requirements, we should have:

* A way to add one or more CTE.
* A way to reference the columns from the CTE.
* A way to join them in the main query.
* Setting a CTE as recursive?
* Choosing if a CTE is materialized or not (Not all DB support that, and 
I'm not sure if they all handle it the same way)?
* Insert / delete CTE with returning data?

Do we have a better idea now of what the API should look like?

Thanks.
Le jeudi 17 octobre 2019 à 23:43:49 UTC+2, buzzi@gmail.com a écrit :

> 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, 
>

RE: Adding generated common table expressions

[Matthew Pava]

I will always suggest that we use the Subquery API to make CTEs. To make them 
recursive, just add a keyword argument (recursive=True) and/or use a union.

It’s been a while since I looked at CTEs, so I might be missing something.

I would hate to see us create an entirely separate API for CTEs.


From: django-developers@googlegroups.com  
On Behalf Of Gaga Ro
Sent: Tuesday, May 10, 2022 9:01 AM
To: Django developers (Contributions to Django itself) 

Subject: Re: Adding generated common table expressions

Hello everyone,

I'm often using django-cte and I'd be thrilled to have CTE in the core.

If I'm not mistaken, the only DB currently supported by Django and not having 
CTE support is MySQL 5.7 (with an end of life in October 2023). I don't know if 
Django 4.2 will support it, but it should be dropped for Django 5.0 as it will 
be released in 2023. So we should have all supported DB supporting CTE when 
this feature would be over.

The ticket (https://code.djangoproject.com/ticket/28919) has been stalled for a 
few years now, this thread as well. I am willing to work on this but I would 
like more information first.

If I try to list all the requirements, we should have:

* A way to add one or more CTE.
* A way to reference the columns from the CTE.
* A way to join them in the main query.
* Setting a CTE as recursive?
* Choosing if a CTE is materialized or not (Not all DB support that, and I'm 
not sure if they all handle it the same way)?
* Insert / delete CTE with returning data?

Do we have a better idea now of what the API should look like?

Thanks.
Le jeudi 17 octobre 2019 à 23:43:49 UTC+2, 
buzzi@gmail.com a écrit :
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,

Re: Adding generated common table expressions

[Gaga Ro]

As far as I know, CTE and subquery are equivalent when used only in a 
single place in the query.

CTE should be better when a single query is used several times.

If we want to reuse the Subquery API, we should find a way to be able to 
reuse a subquery (hash its content and use that as a key to detect the 
duplication?).

Le mardi 10 mai 2022 à 16:08:06 UTC+2, matthew.pava a écrit :

> I will always suggest that we use the Subquery API to make CTEs. To make 
> them recursive, just add a keyword argument (recursive=True) and/or use a 
> union.
>
>  
>
> It’s been a while since I looked at CTEs, so I might be missing something.
>
>  
>
> I would hate to see us create an entirely separate API for CTEs.
>
>  
>
>  
>
> *From:* django-d...@googlegroups.com  *On 
> Behalf Of *Gaga Ro
> *Sent:* Tuesday, May 10, 2022 9:01 AM
> *To:* Django developers (Contributions to Django itself) <
> django-d...@googlegroups.com>
> *Subject:* Re: Adding generated common table expressions
>
>  
>
> Hello everyone,
>
>  
>
> I'm often using django-cte and I'd be thrilled to have CTE in the core.
>
>  
>
> If I'm not mistaken, the only DB currently supported by Django and not 
> having CTE support is MySQL 5.7 (with an end of life in October 2023). I 
> don't know if Django 4.2 will support it, but it should be dropped for 
> Django 5.0 as it will be released in 2023. So we should have all supported 
> DB supporting CTE when this feature would be over.
>
>  
>
> The ticket (https://code.djangoproject.com/ticket/28919) has been stalled 
> for a few years now, this thread as well. I am willing to work on this but 
> I would like more information first.
>
>  
>
> If I try to list all the requirements, we should have:
>
>  
>
> * A way to add one or more CTE.
>
> * A way to reference the columns from the CTE.
>
> * A way to join them in the main query.
>
> * Setting a CTE as recursive?
>
> * Choosing if a CTE is materialized or not (Not all DB support that, and 
> I'm not sure if they all handle it the same way)?
>
> * Insert / delete CTE with returning data?
>
>  
>
> Do we have a better idea now of what the API should look like?
>
>  
>
> Thanks.
>
> Le jeudi 17 octobre 2019 à 23:43:49 UTC+2, buzzi@gmail.com a écrit :
>
> 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 
> 

Equality check for two QuerySet

[mohamad ali mehdizadeh]

Hi.
Why we don't have __eq__ for QuerySets, here is an example:
```
qs1 = Model.objects.all()
qs2 = qs1.all()
qs1 == qs2
```
output: False
as we know these two are the same by value!

-- 
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/80e878f8-8701-40ad-92a0-5c689df27ec2n%40googlegroups.com.

RE: Equality check for two QuerySet

[Danilov Maxim]

I am not Agree.

qs1.all() it is copy from qs1, the new object.

 

I already try to write QuerySet compare on the Django 1.4 and i remember, 

that str(qs1.query) can be different as str(qs2.query), I am not Shure.

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

  ma...@wpsoft.at

 

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of mohamad ali mehdizadeh
Sent: Tuesday, May 10, 2022 5:09 PM
To: Django developers (Contributions to Django itself) 

Subject: Equality check for two QuerySet

 

Hi.
Why we don't have __eq__ for QuerySets, here is an example:
```

qs1 = Model.objects.all()

qs2 = qs1.all()

qs1 == qs2

```

output: False

as we know these two are the same by value!

-- 
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/80e878f8-8701-40ad-92a0-5c689df27ec2n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/000801d864a5%24b65b5550%242311fff0%24%40wpsoft.at.