Re: [Django] #26430: Coalesce in Aggregations ignored when EmptyResultSet returned

[Django]

#26430: Coalesce in Aggregations ignored when EmptyResultSet returned
-+-
 Reporter:  Ryan Prater  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregation  | Triage Stage:  Accepted
  coalesce in queryset   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_patch:  0 => 1


Comment:

 Tried implementing the above in
 https://github.com/django/django/pull/14430

-- 
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.1c7fb39f5c5ff2fad9dc277973c9f4aa%40djangoproject.com.

Re: [Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
-+-
 Reporter:  allen-munsch |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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 allen-munsch):

 support question moved to: https://forum.djangoproject.com/t/django-3-2
 -asgi-uvicorn-is-not-production-ready/8003

-- 
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.cc85fc4a1add6214729907ac785621ed%40djangoproject.com.

Re: [Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
-+-
 Reporter:  allen-munsch |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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
-+-
Description changed by allen-munsch:

Old description:

> Hoping for a bit of guidance here.
>
> How can I contribute to the documentation of using django ASGI in a
> production environment?
>
> Also, Any suggestions on tuning these things for relatively the same
> performance?
>
> Current settings ( seems to perform at about the same )
> py3.8.10
> django3.2
> gunicorn with 18 workers using uvicorn.UvicornWorker
> 9 heroku Performance L instances
>
> Previously
> py3.6.13
> django2.2.5
> gunicorn with 10 workers using eventlet
> 7 heroku Performance L instances
>
> However, notice the two instance difference is quite a bit extra in cost.
>
> wrote out a thing to roughly benchmark django and fastapi being part of
> the same ASGI app.
>
> https://github.com/allen-munsch/benchmark-django-fastapi/
>
> Specifically trying to determine upgrading from django 2.2.5 to django
> 3.2 and layering in FastAPI and running it in a production environment.
>
> Anyone here have any advice on doing that?
>
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/testdjango/asgi_with_static.py
>
> I was thinking these but with gunicorn --workers 18  on 14 heroku
> Performance L instances, and scaling down to 7
>
> https://devcenter.heroku.com/articles/dyno-types
>
> seems like django 3.2 served with uvicorn under peak load is twice as
> slow in a production environment ...
> pretty spiky to 4x slower in comparison to using gunicorn and eventlet
> with the same number of web workers ( 7 heroku Performance L )

New description:

 Hoping for a bit of guidance here.

 How can I contribute to the documentation of using django ASGI in a
 production environment?

 Also, Any suggestions on tuning these things for relatively the same
 performance?

 Current settings ( seems to perform at about the same )
 py3.8.10
 django3.2
 gunicorn with 18 workers using uvicorn.UvicornWorker
 10 heroku Performance L instances

 Previously
 py3.6.13
 django2.2.5
 gunicorn with 10 workers using eventlet
 7 heroku Performance L instances

 However, notice the two instance difference is quite a bit extra in cost.

 wrote out a thing to roughly benchmark django and fastapi being part of
 the same ASGI app.

 https://github.com/allen-munsch/benchmark-django-fastapi/

 Specifically trying to determine upgrading from django 2.2.5 to django 3.2
 and layering in FastAPI and running it in a production environment.

 Anyone here have any advice on doing that?

 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/testdjango/asgi_with_static.py

 I was thinking these but with gunicorn --workers 18  on 14 heroku
 Performance L instances, and scaling down to 7

 https://devcenter.heroku.com/articles/dyno-types

 seems like django 3.2 served with uvicorn under peak load is twice as slow
 in a production environment ...
 pretty spiky to 4x slower in comparison to using gunicorn and eventlet
 with the same number of web workers ( 7 heroku Performance L )

--

-- 
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.84f130d230cc6edce80842120f808f1d%40djangoproject.com.

Re: [Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
-+-
 Reporter:  allen-munsch |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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 Mariusz Felisiak):

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


Old description:

> Hoping for a bit of guidance here.
>
> How can I contribute to the documentation of using django ASGI in a
> production environment?
>
> Also, Any suggestions on tuning these things for relatively the same
> performance?
>
> Current settings ( seems to perform at about the same )
> py3.8.10
> django3.2
> gunicorn with 18 workers using uvicorn.UvicornWorker
> 10 heroku Performance L instances
>
> Previously
> py3.6.13
> django2.2.5
> gunicorn with 10 workers using eventlet
> 7 heroku Performance L instances
>
> However, notice the two instance difference is quite a bit extra in cost.
>
> wrote out a thing to roughly benchmark django and fastapi being part of
> the same ASGI app.
>
> https://github.com/allen-munsch/benchmark-django-fastapi/
>
> Specifically trying to determine upgrading from django 2.2.5 to django
> 3.2 and layering in FastAPI and running it in a production environment.
>
> Anyone here have any advice on doing that?
>
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/testdjango/asgi_with_static.py
>
> I was thinking these but with gunicorn --workers 18  on 14 heroku
> Performance L instances, and scaling down to 7
>
> https://devcenter.heroku.com/articles/dyno-types
>
> seems like django 3.2 served with uvicorn under peak load is twice as
> slow in a production environment ...
> pretty spiky to 4x slower in comparison to using gunicorn and eventlet
> with the same number of web workers ( 7 heroku Performance L )

New description:

 Hoping for a bit of guidance here.

 How can I contribute to the documentation of using django ASGI in a
 production environment?

 Also, Any suggestions on tuning these things for relatively the same
 performance?

 Current settings ( seems to perform at about the same )
 py3.8.10
 django3.2
 gunicorn with 18 workers using uvicorn.UvicornWorker
 9 heroku Performance L instances

 Previously
 py3.6.13
 django2.2.5
 gunicorn with 10 workers using eventlet
 7 heroku Performance L instances

 However, notice the two instance difference is quite a bit extra in cost.

 wrote out a thing to roughly benchmark django and fastapi being part of
 the same ASGI app.

 https://github.com/allen-munsch/benchmark-django-fastapi/

 Specifically trying to determine upgrading from django 2.2.5 to django 3.2
 and layering in FastAPI and running it in a production environment.

 Anyone here have any advice on doing that?

 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/testdjango/asgi_with_static.py

 I was thinking these but with gunicorn --workers 18  on 14 heroku
 Performance L instances, and scaling down to 7

 https://devcenter.heroku.com/articles/dyno-types

 seems like django 3.2 served with uvicorn under peak load is twice as slow
 in a production environment ...
 pretty spiky to 4x slower in comparison to using gunicorn and eventlet
 with the same number of web workers ( 7 heroku Performance L )

--

Comment:

 Ticket description contains  a lot of support questions. Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

-- 
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.402dae5ffc6adb8a7b78090ce55805c2%40djangoproject.com.

Re: [Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
-+-
 Reporter:  allen-munsch |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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 allen-munsch:

Old description:

> Hoping for a bit of guidance here.
>
> How can I contribute to the documentation of using django ASGI in a
> production environment?
>
> Also, Any suggestions on tuning these things for relatively the same
> performance?
>
> Current settings ( seems to perform at about the same )
> py3.8.10
> django3.2
> gunicorn with 18 workers using uvicorn.UvicornWorker
> 9 heroku Performance L instances
>
> Previously
> py3.6.13
> django2.2.5
> gunicorn with 10 workers using eventlet
> 7 heroku Performance L instances
>
> However, notice the two instance difference is quite a bit extra in cost.
>
> wrote out a thing to roughly benchmark django and fastapi being part of
> the same ASGI app.
>
> https://github.com/allen-munsch/benchmark-django-fastapi/
>
> Specifically trying to determine upgrading from django 2.2.5 to django
> 3.2 and layering in FastAPI and running it in a production environment.
>
> Anyone here have any advice on doing that?
>
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
> https://github.com/allen-munsch/benchmark-django-
> fastapi/blob/main/testdjango/asgi_with_static.py
>
> I was thinking these but with gunicorn --workers 18  on 14 heroku
> Performance L instances, and scaling down to 7
>
> https://devcenter.heroku.com/articles/dyno-types
>
> seems like django 3.2 served with uvicorn under peak load is twice as
> slow in a production environment ...
> pretty spiky to 4x slower in comparison to using gunicorn and eventlet
> with the same number of web workers ( 7 heroku Performance L )

New description:

 Hoping for a bit of guidance here.

 How can I contribute to the documentation of using django ASGI in a
 production environment?

 Also, Any suggestions on tuning these things for relatively the same
 performance?

 Current settings ( seems to perform at about the same )
 py3.8.10
 django3.2
 gunicorn with 18 workers using uvicorn.UvicornWorker
 10 heroku Performance L instances

 Previously
 py3.6.13
 django2.2.5
 gunicorn with 10 workers using eventlet
 7 heroku Performance L instances

 However, notice the two instance difference is quite a bit extra in cost.

 wrote out a thing to roughly benchmark django and fastapi being part of
 the same ASGI app.

 https://github.com/allen-munsch/benchmark-django-fastapi/

 Specifically trying to determine upgrading from django 2.2.5 to django 3.2
 and layering in FastAPI and running it in a production environment.

 Anyone here have any advice on doing that?

 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/testdjango/asgi_with_static.py

 I was thinking these but with gunicorn --workers 18  on 14 heroku
 Performance L instances, and scaling down to 7

 https://devcenter.heroku.com/articles/dyno-types

 seems like django 3.2 served with uvicorn under peak load is twice as slow
 in a production environment ...
 pretty spiky to 4x slower in comparison to using gunicorn and eventlet
 with the same number of web workers ( 7 heroku Performance L )

--

-- 
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.8c77b9558a74a258b170a31b4db6a1db%40djangoproject.com.

Re: [Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
-+-
 Reporter:  allen-munsch |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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 allen-munsch):

 * Attachment "Screenshot from 2021-05-21 12-56-13.png" added.

 picture of performance metrics compared to last week

-- 
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.7c2ebced1499342722c859f4c4b280d6%40djangoproject.com.

[Django] #32773: Production Configuration of Django 3.2 with gunicorn and uvicorn

[Django]

#32773: Production Configuration of Django 3.2 with gunicorn and uvicorn
+
   Reporter:  allen-munsch  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.2
   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 |
+
 Hoping for a bit of guidance here.

 How can I contribute to the documentation of using django ASGI in a
 production environment?

 Also, Any suggestions on tuning these things for relatively the same
 performance?

 Current settings ( seems to perform at about the same )
 py3.8.10
 django3.2
 gunicorn with 18 workers using uvicorn.UvicornWorker
 9 heroku Performance L instances

 Previously
 py3.6.13
 django2.2.5
 gunicorn with 10 workers using eventlet
 7 heroku Performance L instances

 However, notice the two instance difference is quite a bit extra in cost.

 wrote out a thing to roughly benchmark django and fastapi being part of
 the same ASGI app.

 https://github.com/allen-munsch/benchmark-django-fastapi/

 Specifically trying to determine upgrading from django 2.2.5 to django 3.2
 and layering in FastAPI and running it in a production environment.

 Anyone here have any advice on doing that?

 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/docker/web/docker-asgi-with-static-entrypoint.sh
 https://github.com/allen-munsch/benchmark-django-
 fastapi/blob/main/testdjango/asgi_with_static.py

 I was thinking these but with gunicorn --workers 18  on 14 heroku
 Performance L instances, and scaling down to 7

 https://devcenter.heroku.com/articles/dyno-types

 seems like django 3.2 served with uvicorn under peak load is twice as slow
 in a production environment ...
 pretty spiky to 4x slower in comparison to using gunicorn and eventlet
 with the same number of web workers ( 7 heroku Performance L )

-- 
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.a13d2abd46aca4871d86a3defea63f4e%40djangoproject.com.

Re: [Django] #32769: Fix for sporadically crashing parallel test runner

[Django]

#32769: Fix for sporadically crashing parallel test runner
---+--
 Reporter:  quinox |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  2.2
 Severity:  Normal |   Resolution:  duplicate
 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 quinox):

 Hey Mariusz,

 Thanks for taking this up.

 I've verified that using Python 3.8.5 and the main branch:
 * **without the patch** the crashes still occur
 * **with the patch** the crashes no longer occur

 I see that with the patch it will create 4 DBs again, even though there
 are only 2 needed (since it can only run 2 classes in parallel). I'm fine
 with this: having Django not crash is far, far more important than the
 ~250ms spent on creating a not-needed DB.

 I'll make a PR using your code.

-- 
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.0f5eddfe14f956383c3b66fd0c864d84%40djangoproject.com.

Re: [Django] #32375: Make Sitemap's protocol default to "https".

[Django]

#32375: Make Sitemap's protocol default to "https".
-+-
 Reporter:  Thomas Güttler   |Owner:  Rohith P
 Type:   |  R
  Cleanup/optimization   |   Status:  closed
Component:  contrib.sitemaps |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sitemap, protocol,   | Triage Stage:  Ready for
  https  |  checkin
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:"7cca22964c09e8dafc313a400c428242404d527a" 7cca2296]:
 {{{
 #!CommitTicketReference repository=""
 revision="7cca22964c09e8dafc313a400c428242404d527a"
 Fixed #32375 -- Started deprecation toward changing the default sitemap
 protocol to https.

 The default sitemap protocol, when it is built outside the context of
 a request, will be changed from 'http' to 'https' in Django 5.0.
 }}}

-- 
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.e73d185559a473983630e4c7100ff6f6%40djangoproject.com.

Re: [Django] #32746: Unexpected test failures in 3.3.2 when running the whole testsuite

[Django]

#32746: Unexpected test failures in 3.3.2 when running the whole testsuite
---+--
 Reporter:  Jakub Kulík|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.2
 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
---+--

Comment (by Mariusz Felisiak):

 Thanks for extra details, unfortunately I still cannot reproduce these
 failures so it must be something Solaris-specific.

-- 
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.ffadc486104d4c387fb73ae1b05401d3%40djangoproject.com.

Re: [Django] #27734: Add a helpful error message when a parallel test worker is assigned an unexpected index

[Django]

#27734: Add a helpful error message when a parallel test worker is assigned an
unexpected index
--+
 Reporter:  Adam Wróbel   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:  parallel  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak):

 #32769 was closed as a duplicate, see
 [https://code.djangoproject.com/ticket/32769#comment:2 comment].

-- 
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.57cf9e6d1e9d4a739c6d37346137accd%40djangoproject.com.

Re: [Django] #32769: Fix for sporadically crashing parallel test runner

[Django]

#32769: Fix for sporadically crashing parallel test runner
---+--
 Reporter:  quinox |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  2.2
 Severity:  Normal |   Resolution:  duplicate
 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 Mariusz Felisiak):

 * cc: Chris Jerdonek (added)
 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Thanks for the report. I think it's a duplicate of #27734, it's not an
 issue with the number of workers, but an issue with a shared counter (see
 [https://code.djangoproject.com/ticket/27734#comment:5 comment]). Reducing
 the number of workers just make it less likely. Can you reproduce it with
 Python 3.8+ and on the main branch? Django 2.2 is in extended support so
 it doesn't receive bugfixes anymore (except security patches).

 I agree that we could reduce the number of workers but it's only a small
 cleanup that will not fix the main issue described in #27734. I would
 reduce the number of processes directly in the `ParallelTestSuite`, e.g.
 {{{
 diff --git a/django/test/runner.py b/django/test/runner.py
 index ab5512e628..50f66d3d87 100644
 --- a/django/test/runner.py
 +++ b/django/test/runner.py
 @@ -405,7 +405,9 @@ class ParallelTestSuite(unittest.TestSuite):

  def __init__(self, suite, processes, failfast=False, buffer=False):
  self.subsuites = partition_suite_by_case(suite)
 -self.processes = processes
 +# Since tests are distributed across processes on a per-TestCase
 basis,
 +# there's no need for more processes than TestCases.
 +self.processes = min(processes, len(self.subsuites))
  self.failfast = failfast
  self.buffer = buffer
  super().__init__()
 @@ -662,14 +664,8 @@ class DiscoverRunner:
  self.failfast,
  self.buffer,
  )
 -
 -# Since tests are distributed across processes on a per-
 TestCase
 -# basis, there's no need for more processes than TestCases.
 -parallel_units = len(parallel_suite.subsuites)
 -self.parallel = min(self.parallel, parallel_units)
 -
  # If there's only one TestCase, parallelization isn't needed.
 -if self.parallel > 1:
 +if parallel_suite.processes > 1:
  suite = parallel_suite

  return suite
 }}}

 Feel-free to prepare a patch with `Refs #27734 -- ...`.

 Duplicate of #27734.

-- 
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.5e243e562a749f8cde93959ded93ca19%40djangoproject.com.

Re: [Django] #32746: Unexpected test failures in 3.3.2 when running the whole testsuite

[Django]

#32746: Unexpected test failures in 3.3.2 when running the whole testsuite
---+--
 Reporter:  Jakub Kulík|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.2
 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
---+--

Comment (by Jakub Kulík):

 I see this issue only with Django 3.2 on SPARC (with both Python 3.7 & 3.9
 and both with and without `--reverse`). Intel in this case is without
 issues, I also don't see this in Django 3.1 or 3.0 with all combinations
 of Python runtime (3.7 and 3.9), architecture (SPARC and Intel), and order
 (`--reverse` or not).

 In each case, tests are executed with the following command:
 `/usr/bin/env LC_ALL=en_US.UTF-8 /usr/bin/python3.x ./runtests.py
 --settings test_sqlite --parallel=1 --verbosity=3 (--reverse)`

-- 
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.9af0862188bbddc9b0f922628dd1ea39%40djangoproject.com.

Re: [Django] #32375: Make Sitemap's protocol default to "https".

[Django]

#32375: Make Sitemap's protocol default to "https".
-+-
 Reporter:  Thomas Güttler   |Owner:  Rohith P
 Type:   |  R
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sitemaps |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  sitemap, protocol,   | Triage Stage:  Ready for
  https  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


-- 
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.da2f9cde7e8b7a927ae27e83bc829e85%40djangoproject.com.

Re: [Django] #32503: AlterField migration to TextField with default fails on MySQL 8.0.13+

[Django]

#32503: AlterField migration to TextField with default fails on MySQL 8.0.13+
-+-
 Reporter:  Matt Westcott|Owner:  yuekui
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  mysql default| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


-- 
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.24be7b972f42af98f43f6ab76fb04751%40djangoproject.com.