Re: [Django] #31925: A typo in FILE_UPLOAD_PERMISSIONS

[Django]

#31925: A typo in FILE_UPLOAD_PERMISSIONS
+--
 Reporter:  Alexey Chernov  |Owner:  Kaustubh
 Type:  Bug |   Status:  assigned
Component:  Documentation   |  Version:  3.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by Kaustubh):

 * owner:  nobody => Kaustubh
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.0a6a3e5a06459020615e11d51456bf76%40djangoproject.com.

[Django] #31925: A typo in FILE_UPLOAD_PERMISSIONS

[Django]

#31925: A typo in FILE_UPLOAD_PERMISSIONS
--+
   Reporter:  Alexey Chernov  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Documentation   |Version:  3.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+
 At https://docs.djangoproject.com/en/3.1/releases/3.0/#new-default-value-
 for-the-file-upload-permissions-setting , please fix
 FILE_UPLOAD_PERMISSION -> FILE_UPLOAD_PERMISSIONS

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.e8d5948ee83b5da335bdc62cd5261cd1%40djangoproject.com.

Re: [Django] #31906: Possible ModelChoiceIterator docs typo

[Django]

#31906: Possible ModelChoiceIterator docs typo
---+-
 Reporter:  Claude Paroz   |Owner:  ninad3188
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-

Comment (by ninad3188):

 The documentation issue is fixed in the below pull request.

 https://github.com/django/django/pull/13336

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f9ec8ef86568d8335da900b8d5b7cabd%40djangoproject.com.

Re: [Django] #31919: Django fails with FieldError: Expression contains mixed types: IntegerField, AutoField. You must set output_field.

[Django]

#31919: Django fails with FieldError: Expression contains mixed types:
IntegerField, AutoField. You must set output_field.
-+-
 Reporter:  StefanosChaliasos|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Stefanos, Would you like to prepare a patch? Simon's proposition works for
 me.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.eb91899d808deca07e974665d843c160%40djangoproject.com.

Re: [Django] #31922: QuerySet.filter() against Q() with Subquery() and __in produces wrong results. (was: Changing ordering of Q statements in filter produces different SQL and results.)

[Django]

#31922: QuerySet.filter() against Q() with Subquery() and __in produces wrong
results.
-+-
 Reporter:  Chris Bell   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, subquery, q,| Triage Stage:  Accepted
  order  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the detailed report, I was able to reproduce this issue.

 Everything works properly with `Exists()`:
 {{{
 >>> q1_exists = Exists(BookStatus.objects.filter(status='DRAFT',
 book__id=OuterRef('pk')))
 >>> q2_exists = ~Exists(BookStatus.objects.filter(status='PUBLISHED',
 book__id=OuterRef('pk')))
 >>> Book.objects.filter(q2_exists & q1_exists)
 ]>
 >>> Book.objects.filter(q1_exists & q2_exists)
 ]>
 }}}

 Reproduced at 41725602afebe2ddb018b99afe134384cc3bf69e.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.76686aa577fb0af308a3d300e0448c04%40djangoproject.com.

Re: [Django] #31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource Policy Headers

[Django]

#31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource
Policy Headers
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  COEP, header, CORP,  | Triage Stage:
  security   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Florian Apolloner, Adam (Chainz) Johnson (added)
 * stage:  Unreviewed => Someday/Maybe


Comment:

 Cross-Origin Embedder Policy spec is still [https://wicg.github.io/cross-
 origin-embedder-policy/ preliminary] and may change at any moment. Also,
 [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-
 Resource-Policy Cross-Origin Resource Policy] is not supported by all
 browser (e.g. Opera) and implementations on Chrome and Firefox have some
 bugs.

 We can reconsider this ticket when specifications and implementations
 become more mature and stable.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.86a052e039755a6219d1d19529d0fed5%40djangoproject.com.

Re: [Django] #31906: Possible ModelChoiceIterator docs typo

[Django]

#31906: Possible ModelChoiceIterator docs typo
---+-
 Reporter:  Claude Paroz   |Owner:  ninad3188
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by ninad3188):

 * owner:  KESHAV KUMAR => ninad3188


Comment:

 Documentation issue is fixed in the below pull request.

 https://github.com/django/django/pull/13335

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.39cd693b717eeb793fd8a46824981677%40djangoproject.com.

Re: [Django] #31877: TemplateView.get_context_data()'s kwargs returns SimpleLazyObjects that causes a crash when filtering.

[Django]

#31877: TemplateView.get_context_data()'s kwargs returns SimpleLazyObjects that
causes a crash when filtering.
-+-
 Reporter:  Tim L. White |Owner:  Adam
 |  (Chainz) Johnson
 Type:  Bug  |   Status:  new
Component:  Generic views|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  1 => 0
 * stage:  Ready for checkin => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.696edc3b56430a8f0f10aa3772c8d37e%40djangoproject.com.

Re: [Django] #31919: Django fails with FieldError: Expression contains mixed types: IntegerField, AutoField. You must set output_field.

[Django]

#31919: Django fails with FieldError: Expression contains mixed types:
IntegerField, AutoField. You must set output_field.
-+-
 Reporter:  StefanosChaliasos|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * severity:  Normal => Release blocker


Comment:

 I confirmed that it's a regression in
 1e38f1191de21b6e96736f58df57dfb851a28c1f.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.017b1155b18b068460ee2712aa7752d4%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by George Tantiras):

 :-D That's life! Django Rocks, nonetheless.

 using modelform_factory() would be a way to defer the form creation
 though

 Thank you, I have not thought of that, it is for sure that I shall give it
 a try.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.58f5a5a1fc9422bf50694122c7e4e237%40djangoproject.com.

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

[Django]

#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
--+
 Reporter:  Michał Górny  |Owner:  Sicong
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Sicong):

 * owner:  nobody => Sicong
 * status:  new => assigned


Comment:

 I'll try to work on this issue.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.576ca4ae46d7dbc0f7476f3b51d9be6b%40djangoproject.com.

Re: [Django] #31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource Policy Headers

[Django]

#31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource
Policy Headers
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  COEP, header, CORP,  | Triage Stage:
  security   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by meggles711):

 * owner:  nobody => meggles711
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.94fb513ec605fb2fe36899391c3a9bbd%40djangoproject.com.

[Django] #31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource Policy Headers

[Django]

#31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource
Policy Headers
-+-
   Reporter: |  Owner:  nobody
  meggles711 |
   Type:  New| Status:  new
  feature|
  Component:  HTTP   |Version:  master
  handling   |   Keywords:  COEP, header, CORP,
   Severity:  Normal |  security
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I would like to add support for the COEP header, as well as CORP which is
 required to support this header, in Django.
 **
 What is Cross-Origin Resource Policy?**
 This header conveys to the browser that it should block no-cors requests
 to the given resource that are cross-origin or cross-site depending on the
 header’s value. This prevents information leaks and blocks the response
 before it enters an attacker’s process.

 The CORP header can have one of three values. If set to “same-origin”, the
 browser will block any cross-origin no-cors requests. If set to “same-
 site”, the browser will block any cross-site no-cors requests. If set to
 “cross-origin”, no-cors requests are explicitly allowed to load this
 resource.

 **What is Cross-Origin Embedder Policy?**
 COEP, when used with the cross-origin opener policy header, is used to
 create a “cross-origin isolated state” for your site. This state prevents
 the modification of document.domain and makes cross-origin requests less
 dangerous. It also allows developers to use otherwise dangerous features
 like SharedBufferArray, performance.measureMemory, and the JS Self-
 Profiling API.

 When set, COEP instructs the browser not to load cross-origin resources
 into the document unless they give explicit permission using CORS or CORP.
 Because of this, COEP can only be effectively used if developers also have
 the ability to set the CORP or CORS header. COEP can only be set to one
 value, “require-corp”.

 **Proposed Changes to Django**
 Django users should have the ability to set the COEP and CORP headers.
 Support for them should be added as a part of the security middleware.
 COEP should default to “require-corp” and CORP should default to “same-
 origin”.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.960d93f55db670dc72b2a112b1dac025%40djangoproject.com.

Re: [Django] #31922: Changing ordering of Q statements in filter produces different SQL and results.

[Django]

#31922: Changing ordering of Q statements in filter produces different SQL and
results.
-+-
 Reporter:  cbellinz |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, subquery, q,| Triage Stage:
  order  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by cbellinz:

Old description:

> This issue has been found when combining two Q statements that filter on
> the same models in subqueries, but with slightly different where clauses.
>
> By combining the two Q in different orders the SQL resulting from the
> queries is different, one producing the correct result and one not. The
> SQL that is not correct has had an additional where clause added to the
> subquery.
>
> Here is an example:
>
> Two simple models (in module = utils)
>
> {{{
> class Book(BaseModel):
> name = models.CharField(max_length=100, null=True, blank=True)
>
> class BookStatus(BaseModel):
> book = models.ForeignKey(Book, null=False, blank=False,
> on_delete=models.CASCADE, related_name='statuses')
> status = models.CharField(max_length=100, null=True, blank=True)
> valid_from = models.DateTimeField(db_index=True)
> valid_to = models.DateTimeField(db_index=True, blank=True, null=True,
> default=None)
> }}}
>
> We will add some data:
>
> from django.utils import timezone
> from utils.models import *
> from django.db.models import Q, Subquery
> b1 = Book.objects.create(name='Green is the new Blue')
> b2 = Book.objects.create(name='Orange is the new Red')
> BookStatus.objects.create(book=b1, status='DRAFT',
> valid_from=timezone.now())
> BookStatus.objects.create(book=b1, status='PUBLISHED',
> valid_from=timezone.now())
> BookStatus.objects.create(book=b2, status='DRAFT',
> valid_from=timezone.now())
>
> Now we want to find all books that are in draft but not published.
>

> {{{
> q1 =
> Q(statuses__id__in=Subquery(BookStatus.objects.only('id').filter(status='DRAFT')))
> q2 =
> ~Q(statuses__id__in=Subquery(BookStatus.objects.only('id').filter(status='PUBLISHED')))
> qs = Book.objects.only('name').filter(q1 & q2)  # NOTICE Q1 BEFORE Q2
> str(qs.query)
> }}}
>
> The resulting query is:
>
> {{{
> SELECT "utils_book"."id",
> "utils_book"."name"
> FROM "utils_book"
> INNER JOIN "utils_bookstatus" ON ("utils_book"."id" =
> "utils_bookstatus"."book_id")
> WHERE (
> "utils_bookstatus"."id" IN (
> SELECT U0."id"
> FROM "utils_bookstatus" U0
> WHERE U0."status" = 'DRAFT'
> )
> AND NOT (
> "utils_book"."id" IN (
> SELECT V1."book_id"
> FROM "utils_bookstatus" V1
> WHERE (
> V1."id" IN (
> SELECT U0."id"
> FROM "utils_bookstatus" U0
> WHERE U0."status" = 'PUBLISHED'
> )
> AND V1."id" = ("utils_bookstatus"."id")
> )
> )
> )
> )
> }}}
>

> You can see the last where clause which joins the inner book status to
> the outer one.
>
> The result being that both books are returned:
>

> {{{
> qs
>
> , ]>
> }}}
>

> Now, if we run the same query again, but reverse the order of the Q I get
> a different result:
>

> {{{
> qs = Book.objects.only('name').filter(q2 & q1)  # NOTICE Q2 BEFORE Q1
>
> str(qs.query)
>

> SELECT "utils_book"."id",
> "utils_book"."name"
> FROM "utils_book"
> INNER JOIN "utils_bookstatus" ON ("utils_book"."id" =
> "utils_bookstatus"."book_id")
> WHERE (
> NOT (
> "utils_book"."id" IN (
> SELECT V1."book_id"
> FROM "utils_bookstatus" V1
> WHERE V1."id" IN (
> SELECT U0."id"
> FROM "utils_bookstatus" U0
> WHERE U0."status" = 'PUBLISHED'
> )
> )
> )
> AND "utils_bookstatus"."id" IN (
> SELECT U0."id"
> FROM "utils_bookstatus" U0
> WHERE U0."status" = 'DRAFT'
> )
> )
> }}}
>
> The result of this query is correct:
>

> {{{
> qs
>
> ]>
> }}}
>

> There are better ways of trying to get the answer this query is looking
> for, but this is a simplification of a more complex scenario and is for
> demoing the issue.
>
> Unfortunately, I have 

[Django] #31922: Changing ordering of Q statements in filter produces different SQL and results.

[Django]

#31922: Changing ordering of Q statements in filter produces different SQL and
results.
-+-
   Reporter:  cbellinz   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  orm, subquery, q,
   Severity:  Normal |  order
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This issue has been found when combining two Q statements that filter on
 the same models in subqueries, but with slightly different where clauses.

 By combining the two Q in different orders the SQL resulting from the
 queries is different, one producing the correct result and one not. The
 SQL that is not correct has had an additional where clause added to the
 subquery.

 Here is an example:

 Two simple models (in module = utils)

 {{{
 class Book(BaseModel):
 name = models.CharField(max_length=100, null=True, blank=True)

 class BookStatus(BaseModel):
 book = models.ForeignKey(Book, null=False, blank=False,
 on_delete=models.CASCADE, related_name='statuses')
 status = models.CharField(max_length=100, null=True, blank=True)
 valid_from = models.DateTimeField(db_index=True)
 valid_to = models.DateTimeField(db_index=True, blank=True, null=True,
 default=None)
 }}}

 We will add some data:

 from django.utils import timezone
 from utils.models import *
 from django.db.models import Q, Subquery
 b1 = Book.objects.create(name='Green is the new Blue')
 b2 = Book.objects.create(name='Orange is the new Red')
 BookStatus.objects.create(book=b1, status='DRAFT',
 valid_from=timezone.now())
 BookStatus.objects.create(book=b1, status='PUBLISHED',
 valid_from=timezone.now())
 BookStatus.objects.create(book=b2, status='DRAFT',
 valid_from=timezone.now())

 Now we want to find all books that are in draft but not published.


 {{{
 q1 =
 
Q(statuses__id__in=Subquery(BookStatus.objects.only('id').filter(status='DRAFT')))
 q2 =
 
~Q(statuses__id__in=Subquery(BookStatus.objects.only('id').filter(status='PUBLISHED')))
 qs = Book.objects.only('name').filter(q1 & q2)  # NOTICE Q1 BEFORE Q2
 str(qs.query)
 }}}

 The resulting query is:

 {{{
 SELECT "utils_book"."id",
 "utils_book"."name"
 FROM "utils_book"
 INNER JOIN "utils_bookstatus" ON ("utils_book"."id" =
 "utils_bookstatus"."book_id")
 WHERE (
 "utils_bookstatus"."id" IN (
 SELECT U0."id"
 FROM "utils_bookstatus" U0
 WHERE U0."status" = 'DRAFT'
 )
 AND NOT (
 "utils_book"."id" IN (
 SELECT V1."book_id"
 FROM "utils_bookstatus" V1
 WHERE (
 V1."id" IN (
 SELECT U0."id"
 FROM "utils_bookstatus" U0
 WHERE U0."status" = 'PUBLISHED'
 )
 AND V1."id" = ("utils_bookstatus"."id")
 )
 )
 )
 )
 }}}


 You can see the last where clause which joins the inner book status to the
 outer one.

 The result being that both books are returned:


 {{{
 qs

 , ]>
 }}}


 Now, if we run the same query again, but reverse the order of the Q I get
 a different result:


 {{{
 qs = Book.objects.only('name').filter(q2 & q1)  # NOTICE Q2 BEFORE Q1

 str(qs.query)


 SELECT "utils_book"."id",
 "utils_book"."name"
 FROM "utils_book"
 INNER JOIN "utils_bookstatus" ON ("utils_book"."id" =
 "utils_bookstatus"."book_id")
 WHERE (
 NOT (
 "utils_book"."id" IN (
 SELECT V1."book_id"
 FROM "utils_bookstatus" V1
 WHERE V1."id" IN (
 SELECT U0."id"
 FROM "utils_bookstatus" U0
 WHERE U0."status" = 'PUBLISHED'
 )
 )
 )
 AND "utils_bookstatus"."id" IN (
 SELECT U0."id"
 FROM "utils_bookstatus" U0
 WHERE U0."status" = 'DRAFT'
 )
 )
 }}}

 The result of this query is correct:


 {{{
 qs

 ]>
 }}}


 There are better ways of trying to get the answer this query is looking
 for, but this is a simplification of a more complex scenario and is for
 demoing the issue.

 Unfortunately, I have not been able to work out why this is happening or
 where in the code the subquery is being amended.

 Regards

 Chris

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with 

Re: [Django] #31906: Possible ModelChoiceIterator docs typo

[Django]

#31906: Possible ModelChoiceIterator docs typo
---+
 Reporter:  Claude Paroz   |Owner:  KESHAV KUMAR
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by KESHAV KUMAR):

 * owner:  nobody => KESHAV KUMAR
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2b719fcd4d6d9bfc758c0a01c0e624b2%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  Michael
 |  Galler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_tests:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e9bd1845c48b72f547bd55c5be1aecd7%40djangoproject.com.

[Django] #31921: Python 3.7: new behavior of os.makedirs breaks FileSystemStorage permissions on intermediate directories

[Django]

#31921: Python 3.7: new behavior of os.makedirs breaks FileSystemStorage
permissions on intermediate directories
-+-
   Reporter:  WhiteSage  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  File   |Version:  3.1
  uploads/storage|   Keywords:  python3.7 makedirs
   Severity:  Normal |  permissions
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 From the python os library documentation
 (https://docs.python.org/3/library/os.html), regarding os.makedirs:
 {{{
 Changed in version 3.7: The mode argument no longer affects the file
 permission bits of newly-created intermediate-level directories.
 }}}
 As FileSystemStorage._save() directly calls os.makedirs all intermediate
 folders will be created with 777 permissions, ignoring the
 directory_permissions_mode member field.

 Steps to reproduce:

 {{{
 django-admin startproject bugreport
 }}}

 Append to settings.py

 {{{
 STATIC_ROOT = BASE_DIR / 'static'

 FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o750
 }}}

 Call
 {{{
 python manage.py collectstatic
 }}}

 Intermediate folders such as static/admin will have permissions 777.

 Note: python version at least 3.7 is required!

 Could have security implications when running on a production server.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9f2c8dc2257fa71ed662922b4610ef7f%40djangoproject.com.

Re: [Django] #31919: Django fails with FieldError: Expression contains mixed types: IntegerField, AutoField. You must set output_field.

[Django]

#31919: Django fails with FieldError: Expression contains mixed types:
IntegerField, AutoField. You must set output_field.
-+-
 Reporter:  StefanosChaliasos|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Database layer (models, ORM)
 * stage:  Unreviewed => Accepted


Comment:

 This is likely a regression caused by
 1e38f1191de21b6e96736f58df57dfb851a28c1f

 Stefanos, could you confirm the following patch addresses your issue

 {{{#!diff
 diff --git a/django/db/models/expressions.py
 b/django/db/models/expressions.py
 index a9768919a2..90d90119d0 100644
 --- a/django/db/models/expressions.py
 +++ b/django/db/models/expressions.py
 @@ -421,6 +421,7 @@ class Expression(BaseExpression, Combinable):

  _connector_combinators = {
  connector: [
 +(fields.IntegerField, fields.IntegerField, fields.IntegerField),
  (fields.IntegerField, fields.DecimalField, fields.DecimalField),
  (fields.DecimalField, fields.IntegerField, fields.DecimalField),
  (fields.IntegerField, fields.FloatField, fields.FloatField),
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.a8c6ee06983b737c4f550421e92380c8%40djangoproject.com.

Re: [Django] #31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if request.user is not unwrapped in sync code

[Django]

#31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if
request.user is not unwrapped in sync code
--+
 Reporter:  Michael Galler|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * cc: Andrew Godwin (added)
 * type:  Cleanup/optimization => New feature
 * stage:  Unreviewed => Accepted


Comment:

 HI Michael, I’m going to accept this as a New Feature.

 I accept totally that you just want to do `request.user`, and that’s
 clearly where we need to go, but I don’t think that’s entailed by the view
 and middleware support in 3.1, so this is something we need to think about
 and address.

 (If you want to help there, that would be cool.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.7241ef6352a9023a4db5b27afc6609e5%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 OK, thanks Simon and Claude for the comments. I’m going to close on that
 basis as expected behaviour.

 George, alas you’re caught in the unfortunate position of using a bug.

 > The example project resulted after stripping down ​django-letsagree
 which uses get_language() (through ​`django-translated-fields`) in the
 ModelForm to allow only certain fields to appear in the relevant admin
 page.

 So, if it’s at import time, as per the example project (which triggers the
 error once the urls loading the views loading the form are included) then
 there’s only one possible value you’re looking for, which is
 `settings.LANGUAGE_CODE` — just use that. (If the form is defined
 dynamically, you should already be OK... — using `modelform_factory()`
 would be a way to defer the form creation though.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c443c9da5105d8f3f80600eb03de454f%40djangoproject.com.

[Django] #31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if request.user is not unwrapped in sync code

[Django]

#31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if
request.user is not unwrapped in sync code
+
   Reporter:  Michael Galler|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.sessions  |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 {{{
 class AuthenticationMiddleware(MiddlewareMixin):
 def process_request(self, request):
 request.user = SimpleLazyObject(lambda: get_user(request))

 }}}

 AuthenticationMiddleware wraps the request.user in a SimpleLazyObject, so
 the Database Query is called lazy

 If i start now a project via django-admin and I add a user and log in and
 request the following view:


 {{{
 from asgiref.sync import sync_to_async
 from django.core.exceptions import SynchronousOnlyOperation
 from django.http import HttpResponse


 @sync_to_async
 def get_user_from_request(request):
 return request.user if bool(request.user) else None


 async def async_test(request):
 # CASE 1
 try:
 print(request.user.is_authenticated)
 except SynchronousOnlyOperation:
 print('error 1')

 # CASE 2
 try:
 user = await sync_to_async(request.user)
 print(user)
 except SynchronousOnlyOperation:
 print('error 2')

 # CASE 3
 try:
 user = await sync_to_async(request.user)()
 print(user)
 except SynchronousOnlyOperation:
 print('error 3')

 # CASE 4
 try:
 user = await sync_to_async(bool)(request.user)
 print(request.user)
 except SynchronousOnlyOperation:
 print('error 4')

 # CASE 5
 try:
 user = await get_user_from_request(request)
 print(user)
 except SynchronousOnlyOperation:
 print('error 5')

 return HttpResponse('Hello, async world!')

 }}}

 Only case 4 and 5 works, i find it a little awkward that i have to do one
 of this cases.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.d8656993cc9b2f5aeaebf7a3dad3d467%40djangoproject.com.

Re: [Django] #31918: in_bulk not working for distinct fields

[Django]

#31918: in_bulk not working for distinct fields
-+-
 Reporter:  Wolph|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  in_bulk distinct | Triage Stage:  Accepted
  queryset   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * keywords:  in_bulk, distinct, queryset => in_bulk distinct queryset
 * type:  Bug => New feature
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 Feature request makes sense, PR with tests is welcome.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5326ac609b04f72dc2a4b0001100086b%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  Michael
 |  Galler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > Should I open another ticket for this ?

 Yes, I think so. If you can narrow it down to a test case, that would be
 **amazing**! . Thanks

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.386a860c9bf09a17350f73022d5873ed%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I didn't dig deep, but calling `get_language()` at import time sounds
 wrong in the first place.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3c95c73098caeb7aef4ba122d2457326%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  Michael
 |  Galler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael Galler):

 I submitted a PR

 Replying to [comment:8 Carlton Gibson]:
 > > That fixes only the problem in the middleware, the connections opened
 in async views are still not closed.
 >
 > I was thinking (and I need to test more to see) that the connection
 opened in the async view would need to be handled via sync_to_async()
 (with thread_sensitive) too.
 > (Then we'd just have one all the way down...) I think that's safe, but
 it's not enforced.
 I think this would be a good solution to overcome this problem.

 I found another problem related to async and the SessionMiddleware

 The request.user is packed in a SimpleLazyObject

 {{{

 class AuthenticationMiddleware(MiddlewareMixin):
 def process_request(self, request):
 request.user = SimpleLazyObject(lambda: get_user(request))
 }}}
 If its not unpacked in another Middlware you cant access it in an async
 view
 None of the following variants work

 {{{
 async def async_test(request):
 user = request.user # Exception SynchronousOnlyOperation
 user = await sync_to_async(request.user)() # Exception
 SynchronousOnlyOperation
 user = await sync_to_async(request.user) # Exception
 SynchronousOnlyOperation
 }}}
 Should I open another ticket for this ?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.dfa2d468673e6a4d6a6c74b163dd3075%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  Michael
 |  Galler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Michael Galler):

 * owner:  nobody => Michael Galler
 * status:  new => assigned
 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.10e54812757164039ede1404c1b092e8%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > That fixes only the problem in the middleware, the connections opened in
 async views are still not closed.

 I was thinking (and I need to test more to see) that the connection opened
 in the async view would need to be handled via sync_to_async() (with
 thread_sensitive) too.
 (Then we'd just have one all the way down...) I think that's safe, but
 it's not enforced.

 Do we need to make accessing the connection and an async unsafe operation,
 I wonder? 樂

 But we need to fix the middleware issue — so I think we should push on
 there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.246ec0eec957f2de3d15ecf756d2c1de%40djangoproject.com.

Re: [Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and PostgreSQL.

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and
PostgreSQL.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  explain, analyze,| Triage Stage:  Ready for
  mariadb, mysql, postgresql |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 Another [https://github.com/django/django/pull/1 PR] for some
 additional minor updates.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6a4ac1938e5af3bcfd6a5cc8a6d63c46%40djangoproject.com.

Re: [Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and PostgreSQL.

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and
PostgreSQL.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  explain, analyze,| Triage Stage:  Ready for
  mariadb, mysql, postgresql |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Nick Pope:

Old description:

> - MySQL 8.0.16+ has support for
> [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-execution-
> plan EXPLAIN FORMAT=TREE].
> - MySQL 8.0.18+ has support for
> [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
> EXPLAIN ANALYZE].
> - MariaDB 10.1.0+ has support for [https://mariadb.com/kb/en/library
> /analyze-statement/ ANALYZE]. (Was `EXPLAIN ANALYZE` before 10.1.0.)
> - PostgreSQL 12+ has support for a new
> [https://www.postgresql.org/docs/12/sql-explain.html#SQL-EXPLAIN
> SETTINGS] option to `EXPLAIN`.

New description:

 - MySQL 8.0.16+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-execution-
 plan EXPLAIN FORMAT=TREE].
 - MySQL 8.0.18+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
 EXPLAIN ANALYZE].
 - MariaDB 10.1.0+ has support for [https://mariadb.com/kb/en/library
 /analyze-statement/ ANALYZE]. (Was `EXPLAIN ANALYZE` before 10.1.0.)
 - PostgreSQL 12+ has support for a new [https://www.postgresql.org/docs/12
 /sql-explain.html#SQL-EXPLAIN SETTINGS] option to `EXPLAIN`.

 Updated 2020-08-20:

 - MySQL 8.0.21+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
 EXPLAIN ANALYZE FORMAT=TREE].
 - PostgreSQL 13+ has support for a new [https://www.postgresql.org/docs/13
 /sql-explain.html#SQL-EXPLAIN WAL] option to `EXPLAIN`.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b7a014cf3ebd3d8b09dbb49d47b65ddc%40djangoproject.com.

[Django] #31919: Django fails with FieldError: Expression contains mixed types: IntegerField, AutoField. You must set output_field.

[Django]

#31919: Django fails with FieldError: Expression contains mixed types:
IntegerField, AutoField. You must set output_field.
-+
   Reporter:  StefanosChaliasos  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I have the following query.


 {{{
 expr = Value(3) * F('id')
 o = Model.objects.using('default')
 res = o.values('field_name').annotate(expr=expr).values('expr')
 print(res)
 }}}

 Unfortunately, this query crashes with a FieldError exception. The track
 trace is


 {{{
 Traceback (most recent call last):
   File "example.py", line 28, in 
 print(res)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 287, in
 __iter__
 self._fetch_all()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 1316, in
 _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 111, in
 __iter__
 for row in compiler.results_iter(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size):
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line
 1115, in results_iter
 results = self.execute_sql(MULTI, chunked_fetch=chunked_fetch,
 chunk_size=chunk_size)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line
 1147, in execute_sql
 sql, params = self.as_sql()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 498,
 in as_sql
 extra_select, order_by, group_by = self.pre_sql_setup()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 55,
 in pre_sql_setup
 self.setup_query()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 46,
 in setup_query
 self.select, self.klass_info, self.annotation_col_map =
 self.get_select()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 267,
 in get_select
 sql, params = col.select_format(self, sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/expressions.py", line 385,
 in select_format
 if hasattr(self.output_field, 'select_format'):
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/utils/functional.py", line 48, in
 __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/expressions.py", line 266,
 in output_field
 output_field = self._resolve_output_field()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/expressions.py", line 463,
 in _resolve_output_field
 return super()._resolve_output_field()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/expressions.py", line 306,
 in _resolve_output_field
 source.__class__.__name__,
 django.core.exceptions.FieldError: Expression contains mixed types:
 IntegerField, AutoField. You must set output_field.
 }}}

 This should be a regression bug because the previous query works in Django
 3.1

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.86be63dbd914a60dba384d460544b09e%40djangoproject.com.

Re: [Django] #31881: Raise Index name limit for postgres

[Django]

#31881: Raise Index name limit for postgres
-+-
 Reporter:  Jarek Glowacki   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  postgres index   | Triage Stage:
  max_name_length|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jarek Glowacki):

 Hey sorry for the slow response.

 Replying to [comment:1 felixxm]:
 > This will break backwards compatibility for `PostgresIndex` subclasses
 with long suffixes, because currently we allow suffixes of any length.

 I had a deeper dig and I don't see how that's the case.. `max_name_length`
 is ''only'' interrogated when:
 - an index name has been automatically constructed:
 
https://github.com/django/django/blob/8c7992f658e1125f8dc20b19206e8bbbe4187372/django/db/models/indexes.py#L118-L121
 - system checks run:
 
https://github.com/django/django/blob/8c7992f658e1125f8dc20b19206e8bbbe4187372/django/db/models/base.py#L1604-L1612

 The code that automatically generates indexes would remain untouched, and
 unaffected:
 
https://github.com/django/django/blob/8c7992f658e1125f8dc20b19206e8bbbe4187372/django/db/models/indexes.py#L110-L117
 It could potentially be relaxed to pad out the hash up to
 `MyIndex.max_name_length`, but I'm not suggesting we change this, and I
 don't think doing so would provide any benefit.

 I've gone ahead and implemented the change here:
 https://github.com/django/django/compare/master...jarekwg:ticket_31881?expand=1

 Please note that `PostgresIndex` isn't used by default for Postgres
 backends, it's only used when inherited by those special Postgres-specific
 Indexes. So the solution I'm suggesting would only help in cases where
 users explicitly specify `PostgresIndex` when defining their custom
 Indexes. Users with custom overrides would still be overriding all this,
 so I don't see how they'd run into regressions.

 The only hardcoded shenanigans i could find that would have trouble if
 suffix length were to change is the one here, but it's oracle-specific
 code, so wouldn't be affected by our work anyway:
 
https://github.com/django/django/blob/8c7992f658e1125f8dc20b19206e8bbbe4187372/django/db/backends/oracle/operations.py#L596

 All that said, I agree that documenting `suffix` and `max_name_length`
 would also be quite helpful. I wouldn't've opened this ticket had there
 been a note in the docs, instructing me to create my own index class with
 these attributes. I'm happy to offer a PR for that too.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e11fb0afce9a2d37b44e976dfd88a06d%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Thanks for the detailed investigation Carlton.

 > Interestingly, the behaviour before that commit (during migrate) was for
 `get_language()` to return `None`. With
 d65b0f72de8d35617fe0554ddabc950c7f323eef it changes to returning
 `LANGUAGE_CODE`. Then with `0b83c8cc` it went back to returning None.
 >
 > I'm inclined to think that using `get_language()` at import time (during
 start-up) shouldn't be supported, since we're not in an active language
 context, but happy to take guidance on that.

 I tend to agree here. If it always returned `None` before
 d65b0f72de8d35617fe0554ddabc950c7f323eef and wasn't tested to return
 `LANGUAGE_CODE` we could maybe accept a ''new feature'' request to make it
 default to `LANGUAGE_CODE` but we can hardly define it as a regression.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.04a4c7ad60f7931c0cc14ccf4d7ead62%40djangoproject.com.

[Django] #31918: in_bulk not working for distinct fields

[Django]

#31918: in_bulk not working for distinct fields
-+-
   Reporter:  Wolph  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  in_bulk, distinct,
   Severity:  Normal |  queryset
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 The `in_bulk` queryset function currently checks for the `pk` field or for
 `unique` fields. But if you do a `queryset.distinct(field)` that field is
 also unique for that queryset so it should be usable for an `in_bulk`.

 I believe the fix would be as easy as patching these lines:
 
https://github.com/django/django/blob/41725602afebe2ddb018b99afe134384cc3bf69e/django/db/models/query.py#L699-L703

 To include `and field_name not in self.query.distinct_fields`

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.81c21b51eab011c1cf6f813e6bf2e714%40djangoproject.com.

[Django] #31917: MySQL Operational Error: "Unknown column 'x' in 'having clause'"

[Django]

#31917: MySQL Operational Error: "Unknown column 'x' in 'having clause'"
-+
   Reporter:  StefanosChaliasos  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I have the following model.


 {{{
 class Example(models.Model):
 id = models.AutoField(primary_key=True,blank=True, null=True)
 f1 = models.IntegerField(blank=True, null=True)
 f2 = models.IntegerField(blank=True, null=True)

 class Meta:
 managed = False
 db_table = 'example'
 }}}

 Based on this model, I perform the following query in a MySQL backend.


 {{{
 x = 5
 expr = Sum(F('f2'))
 o = Example.objects.using('mysql')
 q = o.values('id',
 'f1').annotate(expr=expr).order_by('id','expr','-f1',).filter(expr__gt=(F('f1')
 + Value(x))).values('expr').first()
 }}}

 Unfortunately, this query crashes with an OperationalError exception. The
 track trace is


 {{{
 Traceback (most recent call last):
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 84, in
 _execute
 return self.cursor.execute(sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/mysql/base.py", line 73,
 in execute
 return self.cursor.execute(query, args)
   File "/home/.env/lib/python3.6/site-packages/MySQLdb/cursors.py", line
 206, in execute
 res = self._query(query)
   File "/home/.env/lib/python3.6/site-packages/MySQLdb/cursors.py", line
 319, in _query
 db.query(q)
   File "/home/.env/lib/python3.6/site-packages/MySQLdb/connections.py",
 line 259, in query
 _mysql.connection.query(self, query)
 MySQLdb._exceptions.OperationalError: (1054, "Unknown column 'example.f1'
 in 'having clause'")

 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "example.py", line 25, in 
 q = o.values('id',
 'f1').annotate(expr=expr).order_by('id','expr','-f1',).filter(expr__gt=(F('f1')
 + Value(x))).values('expr').first()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 678, in
 first
 for obj in (self if self.ordered else self.order_by('pk'))[:1]:
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 287, in
 __iter__
 self._fetch_all()
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 1316, in
 _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 111, in
 __iter__
 for row in compiler.results_iter(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size):
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line
 1115, in results_iter
 results = self.execute_sql(MULTI, chunked_fetch=chunked_fetch,
 chunk_size=chunk_size)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line
 1160, in execute_sql
 cursor.execute(sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 98, in
 execute
 return super().execute(sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 66, in
 execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 75, in
 _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 84, in
 _execute
 return self.cursor.execute(sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/utils.py", line 90, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/utils.py", line 84, in
 _execute
 return self.cursor.execute(sql, params)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/backends/mysql/base.py", line 73,
 in execute
 return self.cursor.execute(query, args)
   File "/home/.env/lib/python3.6/site-packages/MySQLdb/cursors.py", 

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael Galler):

 That fixes only the problem in the middleware, the connections opened in
 async views are still not closed.

 I added a print to the open and close in DatabaseWrapper to see what is
 happening

 on a sync view everything works fine:

 {{{
 new connection 102828
 INFO: 127.0.0.1:58775 - "GET /test_sync/ HTTP/1.1" 200 OK
 }}}

 now waiting 10 secs to ensure that connection is closed due
 'CONN_MAX_AGE': 5
 {{{
 close connection 102828
 new connection 102516
 INFO: 127.0.0.1:58775 - "GET /test_sync/ HTTP/1.1" 200 OK
 }}}


 now on async


 {{{
 new connection 98652
 new connection 33540
 INFO: 127.0.0.1:59297 - "GET /test_async/ HTTP/1.1" 200 OK

 #waiting again more than five seconds

 close connection 98652
 new connection 101424
 INFO: 127.0.0.1:59544 - "GET /test_async/ HTTP/1.1" 200 OK
 }}}

 Only one of the two expired connections are closed, the connection in the
 async view is always reused.
 When the postgres server restarts, the async views are broken until the
 application is restarted, because these are never closed.

 The problem is the connection handler create a new databasewrapper for the
 async view due to thread_critical.
 The comment already points out the problem.


 {{{
 def __init__(self, databases=None):
 """
 databases is an optional dictionary of database definitions
 (structured
 like settings.DATABASES).
 """
 self._databases = databases
 # Connections needs to still be an actual thread local, as it's
 truly
 # thread-critical. Database backends should use @async_unsafe to
 protect
 # their code from async contexts, but this will give those
 contexts
 # separate connections in case it's needed as well. There's no
 cleanup
 # after async contexts, though, so we don't allow that if we can
 help it.
 self._connections = Local(thread_critical=True)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6f1e54712890808fdf012c736184d02e%40djangoproject.com.

[Django] #31916: Unexpected crash: TypeError: 'NoneType' object is not iterable

[Django]

#31916: Unexpected crash: TypeError: 'NoneType' object is not iterable
-+
   Reporter:  StefanosChaliasos  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 I have the following models.


 {{{
 from django.db import models


 class M1(models.Model):
 id = models.AutoField(primary_key=True,blank=True, null=True)
 f1 = models.TextField(blank=True, null=True)

 class Meta:
 managed = False
 db_table = 'm1'

 class M2(models.Model):
 id = models.AutoField(primary_key=True,blank=True, null=True)
 f2 = models.TextField(blank=True, null=True)

 class Meta:
 managed = False
 db_table = 'm2'

 class M3(models.Model):
 id = models.AutoField(primary_key=True,blank=True, null=True)
 f3 = models.TextField(blank=True, null=True)

 class Meta:
 managed = False
 db_table = 'm3'
 }}}

 Based on these models, I perform the following query.


 {{{
 o1 = M2.objects.using('default')
 o2 = M1.objects.using('default')
 u1 = o1.union(o2)
 q = u1.order_by('-f2')
 o3 = Whelped.objects.using('default')
 res = q.union(o3)
 print(res.count())
 }}}

 Unfortunately, this query crashes with a TypeError exception. The track
 trace is


 {{{
 Traceback (most recent call last):
   File "example.py", line 19, in 
 print(res.count())
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/query.py", line 411, in
 count
 return self.query.get_count(using=self.db)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/query.py", line 517, in
 get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/query.py", line 485, in
 get_aggregation
 outer_query.add_subquery(inner_query, using)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/subqueries.py", line
 162, in add_subquery
 self.subquery, self.sub_params =
 query.get_compiler(using).as_sql(with_col_aliases=True)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 507,
 in as_sql
 result, params = self.get_combinator_sql(combinator,
 self.query.combinator_all)
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 443,
 in get_combinator_sql
 if compiler.get_order_by():
   File "/home/.env/lib/python3.6/site-
 packages/Django-3.2-py3.6.egg/django/db/models/sql/compiler.py", line 368,
 in get_order_by
 for idx, (sel_expr, _, col_alias) in enumerate(self.select):
 TypeError: 'NoneType' object is not iterable
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.c72abe683021cb42325f77cd1832ce7d%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * resolution:  fixed => invalid


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ac7818c1680f089724f44778fef366d6%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ondřej Kolín):

 * status:  new => closed
 * resolution:   => fixed


Old description:

> 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
> 2. You are able to makemessages and compilemessages
> 3. Django is not picking up the translated messages
> 4. Set the LOCALE_PATHS variable in the settings.py
> 5. django now picks the messages
>
> Fragment of settings.py
> {{{
> LANGUAGE_CODE = 'en'
> LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
> LOCALE_PATHS = (
> os.path.join(BASE_DIR, 'locale'),
> )
> }}}
>
> If this is intended, I think that makemessages/compile messages should
> fail as well. If not, the discovery should work as well.
>
> Basic dir structure
> .
> ├── db.sqlite3
> ├── locale
> ├── manage.py
> ├── safecloud
> ├── secshare
> └── static
>
> cat ./../venv/pyvenv.cfg
> home = /usr/bin
> include-system-site-packages = false
> version = 3.8.3

New description:

 Update: Kinda resolved, see my comment.

 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
 2. You are able to makemessages and compilemessages
 3. Django is not picking up the translated messages
 4. Set the LOCALE_PATHS variable in the settings.py
 5. django now picks the messages

 Fragment of settings.py
 {{{
 LANGUAGE_CODE = 'en'
 LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
 LOCALE_PATHS = (
 os.path.join(BASE_DIR, 'locale'),
 )
 }}}

 If this is intended, I think that makemessages/compile messages should
 fail as well. If not, the discovery should work as well.

 Basic dir structure
 .
 ├── db.sqlite3
 ├── locale
 ├── manage.py
 ├── safecloud
 ├── secshare
 └── static

 cat ./../venv/pyvenv.cfg
 home = /usr/bin
 include-system-site-packages = false
 version = 3.8.3

--

Comment:

 As @felix pointed on irc.freenode.org #django-dev, the behaviour is
 documented.

 But I still think this is kinda bug, or at least inconsistent, because,
 where is the point to be able to gather messages/compile them, but they
 stay unusable in the system, because the var is not set.

 I think, that ./managepy compilemessages should throw a warning at least.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.d9dca0d0c3b5dd769dba6bbb86f25001%40djangoproject.com.

Re: [Django] #31915: Allow load template tag before extends tag

[Django]

#31915: Allow load template tag before extends tag
-+--
 Reporter:  Jann Haber   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I didn't test but you should be able to set the `builtins` option in your
 DTL settings
 
https://docs.djangoproject.com/en/3.1/topics/templates/#django.template.backends.django.DjangoTemplates

 Failing that, you'd need to move the `is_ajax` logic into your view.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8c34c6353f22ea5784d199a74f11ddfe%40djangoproject.com.

Re: [Django] #31905: ASGI: Dead persistent postgres connections are not closed when the database is accessed in middleware

[Django]

#31905: ASGI: Dead persistent postgres connections are not closed when the 
database
is accessed in middleware
-+-
 Reporter:  Michael Galler   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  ASGI Postgres| Triage Stage:  Accepted
  Persistent |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Michael,

 > ... the middleware mixin calls the process_request without
 thread_sensitive, if change this in my middleware the error is gone.

 Right, so here we have it:


 {{{
 async def __acall__(self, request):
 """
 Async version of __call__ that is swapped in when an async request
 is running.
 """
 response = None
 if hasattr(self, 'process_request'):
 response = await sync_to_async(self.process_request)(request)
 response = response or await self.get_response(request)
 if hasattr(self, 'process_response'):
 response = await sync_to_async(self.process_response)(request,
 response)
 return response
 }}}

 
[https://github.com/django/django/blob/41725602afebe2ddb018b99afe134384cc3bf69e/django/utils/deprecation.py#L110-L120
 Src]

 Those `sync_to_async()` calls should use the thread_sensitive parameter.

 We don't really test the actual DB connection teardown but we should be
 able to assert that the middleware gets run in the same thread as the
 calling code, and that the connection is the same
 (`thread.get_native_id()` and `id(connection)`, assuming we can't pass the
 actual objects 樂)

 Not 100% sure on the test location but
 `tests/deprecation/test_middleware_mixin.py` seems a reasonable candidate.
 (If we need views and urls, because we need the handler itself then, there
 are already some set up in `tests/handlers`, which might then be a better
 place.)

 How does that sound Micheal? Would you fancy making a PR?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b2dbc8bd8e4a760d298218310c4e3004%40djangoproject.com.

Re: [Django] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
-+-
 Reporter:  Tetsuya Morimoto |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  multi-db | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Menno Manheim):

 * cc: Menno Manheim (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.d073318762ad9f105e0457e8fd904ef5%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by George Tantiras):

 The example project resulted after stripping down
 [https://github.com/raratiru/django-letsagree, django-letsagree] which
 uses `get_language` (through [https://github.com/matthiask/django-
 translated-fields, `django-translated-fields`]) in the `ModelForm` to
 allow only certain fields to appear in the relevant admin page.

 As a user who has set `USE_I18N  = True`, I would expect of `get_language`
 to at least return the default language, as per the "notion" I get from
 the docs of [https://docs.djangoproject.com/en/dev/ref/settings/#language-
 code, `LANGUAGE_CODE`]:


 It serves two purposes:
 *If the locale middleware isn’t in use, it decides which translation
 is served to all users.
 *If the locale middleware is active, it provides a fallback language
 in case the user’s preferred language can’t be determined or is not
 supported by the website. It also provides the fallback translation
 when a translation for a given literal doesn’t exist for the user’s
 preferred language.

 "Notion": `@no_translations` ~= "the locale middleware isn’t in use"

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.1a5dab231c3d442fccde84b61a50ebb0%40djangoproject.com.

[Django] #31915: Allow load template tag before extends tag

[Django]

#31915: Allow load template tag before extends tag
---+
   Reporter:  Jann Haber   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Currently the extends template tag always needs to be the first template
 tag used in a template (if it is used at all). In the extends tag, it is
 possible to use the built-in template tags. For example, with Django 3.0,
 we have been using different base templates depending on if a request was
 an ajax request or not:

 {{{
 {% extends request.is_ajax|yesno:"base_ajax.html,base.html" %}
 }}}

 Once the is_ajax method is removed from the request objects, this is not
 possible anymore. A new template tag for "is_ajax" could be created (like
 {{{ {% extends request|is_ajax|yesno... %} }}}), but it is not possible to
 load it before extends, since extends always needs to be the first
 template tag. The only possible workaround I see to achieve the same
 behaviour, is to create a context processor, however this will be
 processed for all requests, even the ones that don't need this feature.

 All in all, I am requesting to allow load template tags before "extends".

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.ce3d1dbbc7243d8313789dc558118945%40djangoproject.com.

Re: [Django] #31508: ASGI Lifespan Support

[Django]

#31508: ASGI Lifespan Support
---+
 Reporter:  Braunson   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  3.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Narbonne):

 * cc: Narbonne (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cbd3c3b76484a22d6aa4b9733809e7d0%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ondřej Kolín:

Old description:

> 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
> 2. You are able to makemessages and compilemessages
> 3. Django is not picking up the translated messages
> 4. Set the LOCALE_PATHS variable in the settings.py
> 5. django now picks the messages
>
> Fragment of settings.py
> {{{
> LANGUAGE_CODE = 'en'
> LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
> LOCALE_PATHS = (
> os.path.join(BASE_DIR, 'locale'),
> )
> }}}
>
> If this is intended, I think that makemessages/compile messages should
> fail as well. If not, the discovery should work as well.
>
> Basic dir structure
> .
> ├── db.sqlite3
> ├── locale
> ├── manage.py
> ├── safecloud
> ├── secshare
> └── static

New description:

 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
 2. You are able to makemessages and compilemessages
 3. Django is not picking up the translated messages
 4. Set the LOCALE_PATHS variable in the settings.py
 5. django now picks the messages

 Fragment of settings.py
 {{{
 LANGUAGE_CODE = 'en'
 LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
 LOCALE_PATHS = (
 os.path.join(BASE_DIR, 'locale'),
 )
 }}}

 If this is intended, I think that makemessages/compile messages should
 fail as well. If not, the discovery should work as well.

 Basic dir structure
 .
 ├── db.sqlite3
 ├── locale
 ├── manage.py
 ├── safecloud
 ├── secshare
 └── static

 cat ./../venv/pyvenv.cfg
 home = /usr/bin
 include-system-site-packages = false
 version = 3.8.3

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.6463c63d189ef1b818a2fb271e86f8bc%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ondřej Kolín:

Old description:

> 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
> 2. You are able to makemessages and compilemessages
> 3. Django is not picking up the translated messages
> 4. Set the LOCALE_PATHS variable in the settings.py
> 5. django now picks the messages
>
> Fragment of settings.py
> {{{
> LANGUAGE_CODE = 'en'
> LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
> LOCALE_PATHS = (
> os.path.join(BASE_DIR, 'locale'),
> )
> }}}
>
> If this is intended, I think that makemessages/compile messages should
> fail as well. If not, the discovery should work as well.

New description:

 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
 2. You are able to makemessages and compilemessages
 3. Django is not picking up the translated messages
 4. Set the LOCALE_PATHS variable in the settings.py
 5. django now picks the messages

 Fragment of settings.py
 {{{
 LANGUAGE_CODE = 'en'
 LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
 LOCALE_PATHS = (
 os.path.join(BASE_DIR, 'locale'),
 )
 }}}

 If this is intended, I think that makemessages/compile messages should
 fail as well. If not, the discovery should work as well.

 Basic dir structure
 .
 ├── db.sqlite3
 ├── locale
 ├── manage.py
 ├── safecloud
 ├── secshare
 └── static

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.c8ec22c29e9ecc1ea6cc2f0a6b959f8a%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ondřej Kolín):

 * Attachment "with_locales_path_set.png" added.


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.bda4ff0521a463a5f62f1d781cf8e9b8%40djangoproject.com.

Re: [Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
-+-
 Reporter:  Ondřej Kolín |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ondřej Kolín):

 * Attachment "without_locales_path_set.png" added.

 Without locales path set

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.675560882c46cd40cf0a36789e869afb%40djangoproject.com.

[Django] #31914: Django does not pick up .mo files when LOCALE_PATHS is unset

[Django]

#31914: Django does not pick up .mo files when LOCALE_PATHS is unset
+
   Reporter:  Ondřej Kolín  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Internationalization  |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 1. Set LANGUAGE_CODE and LANGUAGES in settings.py
 2. You are able to makemessages and compilemessages
 3. Django is not picking up the translated messages
 4. Set the LOCALE_PATHS variable in the settings.py
 5. django now picks the messages

 Fragment of settings.py
 {{{
 LANGUAGE_CODE = 'en'
 LANGUAGES =[ ('en', _('English')), ('cs', _('Czech')) ]
 LOCALE_PATHS = (
 os.path.join(BASE_DIR, 'locale'),
 )
 }}}

 If this is intended, I think that makemessages/compile messages should
 fail as well. If not, the discovery should work as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.87e413ec55eefcd17363e249ffa48c5e%40djangoproject.com.

Re: [Django] #31900: Reloader using watchman initiates reloads despite no file changed

[Django]

#31900: Reloader using watchman initiates reloads despite no file changed
---+--
 Reporter:  Julien Chol|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:  worksforme
 Keywords:  reloader watchman  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Hi sorry, I can't reproduce this.

 I rebuild from your Dockefile and run without any issue.

 I strongly suspect this is some Docker config issue.

 Very happy to re-open if we can demonstrate an issue in Django.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.2b3d79377549df63f6727738d562c5d4%40djangoproject.com.

Re: [Django] #31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during ./manage.py migrate

[Django]

#31911: Django-3.1: get_language() fails to return LANGUAGE_CODE during 
./manage.py
migrate
-+-
 Reporter:  George Tantiras  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Claude Paroz, Simon Charette (added)


Comment:

 OK, this is a goody.

 To be clear the issue is that `get_language()` returns `None` in the
 context of
 a `migrate` command on 3.1, but `settings.LANGUAGE_CODE` (so `en-us`) on
 3.0.

 In the example project this manifests when the result of `get_language()`
 is interpolated into a field name on a `ModelForm` — either way there's an
 error, it's just what the missing field is called that's at stake.

 So, on Django 3.0:


 {{{
 from letsagree.views import PendingView
   File "/Users/carlton/Desktop/ticket_31911/letsagree/views.py", line 2,
 in 
 from letsagree.forms import TestView
   File "/Users/carlton/Desktop/ticket_31911/letsagree/forms.py", line 6,
 in 
 class PendingConsentForm(forms.ModelForm):
   File "/Users/carlton/Documents/Django-
 Stack/django/django/forms/models.py", line 267, in __new__
 raise FieldError(message)
 django.core.exceptions.FieldError: Unknown field(s) (summary_en-us)
 specified for Term
 }}}


 vs Django 3.1:


 {{{
 from letsagree.views import PendingView
   File "/Users/carlton/Desktop/ticket_31911/letsagree/views.py", line 2,
 in 
 from letsagree.forms import TestView
   File "/Users/carlton/Desktop/ticket_31911/letsagree/forms.py", line 6,
 in 
 class PendingConsentForm(forms.ModelForm):
   File "/Users/carlton/Documents/Django-
 Stack/django/django/forms/models.py", line 267, in __new__
 raise FieldError(message)
 django.core.exceptions.FieldError: Unknown field(s) (summary_None)
 specified for Term
 }}}


 Other commands, e.g. `check` do not trigger this difference. That is
 because
 `migrate` runs with the `@no_translations` decorator applied.

 In this context, it looks like the 3.1 behaviour is correct:

 > **get_language()**: Returns the currently selected language code.
 Returns `None` if translations are temporarily deactivated (by
 `deactivate_all()` or when None is passed to `override()`).

 Reading that, I'm expecting `None` here when `@no_translations` is in
 play.

 The change in behaviour occurs in Simon's
 0b83c8cc4db95812f1e15ca19d78614e94cf38dd.

 From the change there to `migrate.py`, it looks like it must have
 something to do with:

 > This also removes unnecessary `BaseCommand._run_checks()`` hook.

 (But I didn't yet experiment reverting that bit.)

 `@no_translations` was introduced by Claude in
 d65b0f72de8d35617fe0554ddabc950c7f323eef (for Django 2.1).

 Interestly, the behaviour before that commit (during `migrate`) was for
 `get_language()` to return `None`. With d65b0f72 it changes to returning
 `LANGUAGE_CODE`. Then with 0b83c8cc it went back to returning `None`.

 So we need to decide what to say...

 I'm inclined to think that using `get_language()` at import time (during
 start-up) shouldn't be supported, since we're not in an active language
 context, but happy to take guidance on that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.931fe8f23a2220969a5bca4f1b96cbaa%40djangoproject.com.

Re: [Django] #29887: Add support for pymemcache

[Django]

#29887: Add support for pymemcache
-+-
 Reporter:  Adrian Turjak|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  pymemcache   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e2013b260a8f689eee280d00b96a9507895ec236" e2013b26]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2013b260a8f689eee280d00b96a9507895ec236"
 Refs #29887, #27480 -- Moved touch() to BaseMemcachedCache.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b10e3b3cd2d39ecbb75fd25af6752e0a%40djangoproject.com.

Re: [Django] #27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method

[Django]

#27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method
-+-
 Reporter:  Victor Porton|Owner:  Nicolas
 |  Noé
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e2013b260a8f689eee280d00b96a9507895ec236" e2013b26]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2013b260a8f689eee280d00b96a9507895ec236"
 Refs #29887, #27480 -- Moved touch() to BaseMemcachedCache.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1fea98cd9ff72400662e4e7e8d41a4bb%40djangoproject.com.

Re: [Django] #31913: PasswordResetConfirmView results in NoReverseMarch (was: url PasswordResetConfirmView results in NoReverseMarch)

[Django]

#31913: PasswordResetConfirmView results in NoReverseMarch
--+--
 Reporter:  bvermeulen|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  3.1
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Uncategorized => contrib.auth


Comment:

 In Django 3.1, the password reset mechanism uses the SHA-256 hashing
 algorithm for tokens, see da4923ea87124102aae4455e947ce24599c0365b. You're
 regexp is too strict, you should use `path('reset///',
 ...)` as
 [https://docs.djangoproject.com/en/3.1/ref/contrib/admin/#adding-a
 -password-reset-feature documented].

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.87e2cef14f3ddc0396395e5c66a9defc%40djangoproject.com.

Re: [Django] #31912: pathlib PermissionError problem

[Django]

#31912: pathlib PermissionError problem
---+--
 Reporter:  leonyxz|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  3.1
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Hi. Interesting. I'm struggling to see what if anything we can or should
 do here.

 So this is the call we're making:

 > `BASE_DIR = Path(__file__).resolve(strict=True).parent.parent`

 from `settings.py`.

 If that raises `PermissionDenied` then (surely, I want to say) your
 permissions are just set wrong (too strict).

 I can't see how it's meant to be an issue in Django?

 (Sorry if I'm missing it...)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f6e20a227ecec826155b1b902d813599%40djangoproject.com.

Re: [Django] #31906: Possible ModelChoiceIterator docs typo

[Django]

#31906: Possible ModelChoiceIterator docs typo
---+
 Reporter:  Claude Paroz   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Claude Paroz):

 Don't ask, just take it when it is not already assigned.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bd1b6266ba757565492436b4a374ee25%40djangoproject.com.

Re: [Django] #31909: Context processor mention in the AdminSite.enable_nav_sidebar requirements is incorrect.

[Django]

#31909: Context processor mention in the AdminSite.enable_nav_sidebar 
requirements
is incorrect.
-+-
 Reporter:  Enderson Menezes |Owner:  Enderson
 |  Menezes
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  nav sidebar bug 3.1  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"26ccc7701daa77c72f467fdad9fedd0165531875" 26ccc770]:
 {{{
 #!CommitTicketReference repository=""
 revision="26ccc7701daa77c72f467fdad9fedd0165531875"
 [3.1.x] Fixed #31909 -- Fixed typo in docs/ref/contrib/admin/index.txt.

 Backport of 67e4a9a4b9a40609fecc14f1604929ff2259a15a from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.5ed19ef060388cc0660dd385de7c5b9e%40djangoproject.com.

Re: [Django] #31909: Context processor mention in the AdminSite.enable_nav_sidebar requirements is incorrect.

[Django]

#31909: Context processor mention in the AdminSite.enable_nav_sidebar 
requirements
is incorrect.
-+-
 Reporter:  Enderson Menezes |Owner:  Enderson
 |  Menezes
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  nav sidebar bug 3.1  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"67e4a9a4b9a40609fecc14f1604929ff2259a15a" 67e4a9a]:
 {{{
 #!CommitTicketReference repository=""
 revision="67e4a9a4b9a40609fecc14f1604929ff2259a15a"
 Fixed #31909 -- Fixed typo in docs/ref/contrib/admin/index.txt.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.988bfbd713c2a6486161050edc76de80%40djangoproject.com.

Re: [Django] #31908: Add parallel testing support to Oracle backend

[Django]

#31908: Add parallel testing support to Oracle backend
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, parallel,| Triage Stage:  Accepted
  tests  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.25320143cd30e4c48b4c17761518aec6%40djangoproject.com.

Re: [Django] #31907: Inconsistent key validation checks in cache backends.

[Django]

#31907: Inconsistent key validation checks in cache backends.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.3b2ac3ef97b9f19bc7a5fa98dfc6cb41%40djangoproject.com.