Re: [Django] #34084: Regression in Django 4.1 so ModelForms always set self.instance even when none passed in

[Django]

#34084: Regression in Django 4.1 so ModelForms always set self.instance even 
when
none passed in
--+--
 Reporter:  Steven Mapes  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  4.1
 Severity:  Normal|   Resolution:
 Keywords:  modelform | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by David Kwong):

 * cc: David Kwong (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/01070183c9eb557c-97ee0e20-7527-4c15-a40d-18914f0067b9-00%40eu-central-1.amazonses.com.

Re: [Django] #28000: Avoid SET/DROP DEFAULT unless a field changes from null to non-null

[Django]

#28000: Avoid SET/DROP DEFAULT unless a field changes from null to non-null
-+-
 Reporter:  Matteo Pietro Russo  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 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 Tim Graham):

 Leaving database defaults would be backward incompatible and could result
 in surprising behavior. `Field.default` can be a callable which returns a
 non-static value that could be inappropriate as a long-running default.

 #470 is a new feature ticket to allow using database defaults.

-- 
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/01070183c8b2d8c0-2080eeb1-24a0-4621-adf9-aefd760d3e94-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startproject black   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jeff Triplett):

 The `.ini` file is a red herring here from my example. It's a `.in` (no
 extra i) that Django seems to be passing through to Black somehow. I have
 used Black for years and I have never had either file extension processed
 by Black.

-- 
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/01070183c8a76598-8feacae6-634d-4803-a4f8-a95d5c308e59-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startproject black   | 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):

 As far as I'm aware, excluding `.ini` files is something that should be
 controlled by a local `Black` configuration, not by Django itself.

-- 
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/01070183c89de31d-4d93b9e3-1c57-4282-a54c-18649044421c-00%40eu-central-1.amazonses.com.

Re: [Django] #34086: Confirm support for PostGIS 3.3

[Django]

#34086: Confirm support for PostGIS 3.3
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgis  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/01070183c8906326-a6d27bd9-b397-4e67-b2c0-9a497e9956bd-00%40eu-central-1.amazonses.com.

Re: [Django] #34086: Confirm support for PostGIS 3.3

[Django]

#34086: Confirm support for PostGIS 3.3
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgis  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Paolo Melchiorre:

Old description:

> I checked that the tests pass on PostGIS 3.3.
>
> == Files
>
> `postgis.py`
> {{{
> #!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'HOST': 'postgres',
> 'NAME': 'geodjango',
> 'PASSWORD': 'postgres',
> 'PORT': 5432,
> 'USER': 'postgres',
> },
> 'other': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'HOST': 'postgres',
> 'NAME': 'other',
> 'PASSWORD': 'postgres',
> 'PORT': 5433,
> 'USER': 'postgres',
> },
> }
>
> SECRET_KEY = 'django_tests_secret_key'
>
> USE_TZ = False
> }}}
>
> `docker-compose.yaml`
> {{{
> #!yaml
> services:
>
>   geodjango:
> environment:
>   - POSTGRES_DB=geodjango
>   - POSTGRES_PASSWORD=postgres
> image: postgis/postgis:14-3.3
> ports:
>   - "5432:5432"
> volumes:
>   - geodjango_data:/var/lib/postgresql/data
>
>   other:
> environment:
>   - POSTGRES_DB=other
>   - POSTGRES_PASSWORD=postgres
> image: postgis/postgis:14-3.3
> ports:
>   - "5433:5432"
> volumes:
>   - other_data:/var/lib/postgresql/data
>
> volumes:
>   geodjango_data: {}
>   other_data: {}
> }}}
>
> == Test
>
> {{{
> #!bash
> (django) paulox@net:~/Projects/django/tests$ time ./runtests.py
> --settings=postgis gis_tests --timing -v0
> System check identified 52 issues (1 silenced).
> --
> Ran 553 tests in 23.196s
>
> OK (skipped=20)
> Total database setup took 14.557s
>   Creating 'default' took 2.982s
>   Cloning 'default' took 0.639s
>   Cloning 'default' took 0.481s
>   Cloning 'default' took 0.564s
>   Cloning 'default' took 0.542s
>   Cloning 'default' took 0.551s
>   Cloning 'default' took 0.475s
>   Cloning 'default' took 0.452s
>   Cloning 'default' took 0.470s
>   Creating 'other' took 3.105s
>   Cloning 'other' took 0.598s
>   Cloning 'other' took 0.550s
>   Cloning 'other' took 0.539s
>   Cloning 'other' took 0.550s
>   Cloning 'other' took 0.522s
>   Cloning 'other' took 0.601s
>   Cloning 'other' took 0.480s
>   Cloning 'other' took 0.454s
> Total database teardown took 2.556s
> Total run took 40.594s
> }}}

New description:

 I checked that the tests pass on PostGIS 3.3.

 == Files

 `postgis.py`
 {{{
 #!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'geodjango',
 'PASSWORD': 'postgres',
 'PORT': 5432,
 'USER': 'postgres',
 },
 'other': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'other',
 'PASSWORD': 'postgres',
 'PORT': 5433,
 'USER': 'postgres',
 },
 }

 SECRET_KEY = 'django_tests_secret_key'

 USE_TZ = False
 }}}

 `docker-compose.yaml`
 {{{
 #!yaml
 services:

   geodjango:
 environment:
   - POSTGRES_DB=geodjango
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5432:5432"
 volumes:
   - geodjango_data:/var/lib/postgresql/data

   other:
 environment:
   - POSTGRES_DB=other
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5433:5432"
 volumes:
   - other_data:/var/lib/postgresql/data

 volumes:
   geodjango_data: {}
   other_data: {}
 }}}

 == Test

 {{{
 #!shell
 (django) paulox@net:~/Projects/django/tests$ ./runtests.py
 --settings=postgis gis_tests --timing -v0
 System check identified 52 issues (1 silenced).
 --
 Ran 553 tests in 23.196s

 OK (skipped=20)
 Total database setup took 14.557s
   Creating 'default' took 2.982s
   Cloning 'default' took 0.639s
   Cloning 'default' took 0.481s
   Cloning 'default' took 0.564s
   Cloning 'default' took 0.542s
   Cloning 'default' took 0.551s
   Cloning 'default' took 0.475s
   Cloning 'default' took 0.452s
   Cloning 'default' took 0.470s
   Creating 'other' 

Re: [Django] #34086: Confirm support for PostGIS 3.3

[Django]

#34086: Confirm support for PostGIS 3.3
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgis  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Paolo Melchiorre:

Old description:

> I checked that the tests pass on PostGIS 3.3.
>
> == Files
>
> `postgis.py`
> {{{
> #!python
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'HOST': 'postgres',
> 'NAME': 'geodjango',
> 'PASSWORD': 'postgres',
> 'PORT': 5432,
> 'USER': 'postgres',
> },
> 'other': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'HOST': 'postgres',
> 'NAME': 'other',
> 'PASSWORD': 'postgres',
> 'PORT': 5433,
> 'USER': 'postgres',
> },
> }
>
> SECRET_KEY = 'django_tests_secret_key'
>
> USE_TZ = False
> }}}
>
> `docker-compose.yaml`
> {{{
> #!yaml
> services:
>
>   geodjango:
> environment:
>   - POSTGRES_DB=geodjango
>   - POSTGRES_PASSWORD=postgres
> image: postgis/postgis:14-3.3
> ports:
>   - "5432:5432"
> volumes:
>   - geodjango_data:/var/lib/postgresql/data
>
>   other:
> environment:
>   - POSTGRES_DB=other
>   - POSTGRES_PASSWORD=postgres
> image: postgis/postgis:14-3.3
> ports:
>   - "5433:5432"
> volumes:
>   - other_data:/var/lib/postgresql/data
>
> volumes:
>   geodjango_data: {}
>   other_data: {}
> }}}
>
> == Test
>
> {{{
> #!python
> (django) paulox@net:~/Projects/django/tests$ time ./runtests.py
> --settings=postgis gis_tests --timing -v0
> System check identified 52 issues (1 silenced).
> --
> Ran 553 tests in 23.196s
>
> OK (skipped=20)
> Total database setup took 14.557s
>   Creating 'default' took 2.982s
>   Cloning 'default' took 0.639s
>   Cloning 'default' took 0.481s
>   Cloning 'default' took 0.564s
>   Cloning 'default' took 0.542s
>   Cloning 'default' took 0.551s
>   Cloning 'default' took 0.475s
>   Cloning 'default' took 0.452s
>   Cloning 'default' took 0.470s
>   Creating 'other' took 3.105s
>   Cloning 'other' took 0.598s
>   Cloning 'other' took 0.550s
>   Cloning 'other' took 0.539s
>   Cloning 'other' took 0.550s
>   Cloning 'other' took 0.522s
>   Cloning 'other' took 0.601s
>   Cloning 'other' took 0.480s
>   Cloning 'other' took 0.454s
> Total database teardown took 2.556s
> Total run took 40.594s
> }}}

New description:

 I checked that the tests pass on PostGIS 3.3.

 == Files

 `postgis.py`
 {{{
 #!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'geodjango',
 'PASSWORD': 'postgres',
 'PORT': 5432,
 'USER': 'postgres',
 },
 'other': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'other',
 'PASSWORD': 'postgres',
 'PORT': 5433,
 'USER': 'postgres',
 },
 }

 SECRET_KEY = 'django_tests_secret_key'

 USE_TZ = False
 }}}

 `docker-compose.yaml`
 {{{
 #!yaml
 services:

   geodjango:
 environment:
   - POSTGRES_DB=geodjango
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5432:5432"
 volumes:
   - geodjango_data:/var/lib/postgresql/data

   other:
 environment:
   - POSTGRES_DB=other
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5433:5432"
 volumes:
   - other_data:/var/lib/postgresql/data

 volumes:
   geodjango_data: {}
   other_data: {}
 }}}

 == Test

 {{{
 #!bash
 (django) paulox@net:~/Projects/django/tests$ time ./runtests.py
 --settings=postgis gis_tests --timing -v0
 System check identified 52 issues (1 silenced).
 --
 Ran 553 tests in 23.196s

 OK (skipped=20)
 Total database setup took 14.557s
   Creating 'default' took 2.982s
   Cloning 'default' took 0.639s
   Cloning 'default' took 0.481s
   Cloning 'default' took 0.564s
   Cloning 'default' took 0.542s
   Cloning 'default' took 0.551s
   Cloning 'default' took 0.475s
   Cloning 'default' took 0.452s
   Cloning 'default' took 0.470s
   Creating 

Re: [Django] #34086: Confirm support for PostGIS 3.3

[Django]

#34086: Confirm support for PostGIS 3.3
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgis  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Melchiorre):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/16171 PR #16171]

-- 
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/01070183c8557280-2573ec58-a332-4f31-bab1-c18562273427-00%40eu-central-1.amazonses.com.

[Django] #34086: Confirm support for PostGIS 3.3

[Django]

#34086: Confirm support for PostGIS 3.3
-+-
   Reporter:  Paolo  |  Owner:  Paolo Melchiorre
  Melchiorre |
   Type:  New| Status:  assigned
  feature|
  Component:  GIS|Version:  dev
   Severity:  Normal |   Keywords:  postgis
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I checked that the tests pass on PostGIS 3.3.

 == Files

 `postgis.py`
 {{{
 #!python
 DATABASES = {
 'default': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'geodjango',
 'PASSWORD': 'postgres',
 'PORT': 5432,
 'USER': 'postgres',
 },
 'other': {
 'ENGINE': 'django.contrib.gis.db.backends.postgis',
 'HOST': 'postgres',
 'NAME': 'other',
 'PASSWORD': 'postgres',
 'PORT': 5433,
 'USER': 'postgres',
 },
 }

 SECRET_KEY = 'django_tests_secret_key'

 USE_TZ = False
 }}}

 `docker-compose.yaml`
 {{{
 #!yaml
 services:

   geodjango:
 environment:
   - POSTGRES_DB=geodjango
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5432:5432"
 volumes:
   - geodjango_data:/var/lib/postgresql/data

   other:
 environment:
   - POSTGRES_DB=other
   - POSTGRES_PASSWORD=postgres
 image: postgis/postgis:14-3.3
 ports:
   - "5433:5432"
 volumes:
   - other_data:/var/lib/postgresql/data

 volumes:
   geodjango_data: {}
   other_data: {}
 }}}

 == Test

 {{{
 #!python
 (django) paulox@net:~/Projects/django/tests$ time ./runtests.py
 --settings=postgis gis_tests --timing -v0
 System check identified 52 issues (1 silenced).
 --
 Ran 553 tests in 23.196s

 OK (skipped=20)
 Total database setup took 14.557s
   Creating 'default' took 2.982s
   Cloning 'default' took 0.639s
   Cloning 'default' took 0.481s
   Cloning 'default' took 0.564s
   Cloning 'default' took 0.542s
   Cloning 'default' took 0.551s
   Cloning 'default' took 0.475s
   Cloning 'default' took 0.452s
   Cloning 'default' took 0.470s
   Creating 'other' took 3.105s
   Cloning 'other' took 0.598s
   Cloning 'other' took 0.550s
   Cloning 'other' took 0.539s
   Cloning 'other' took 0.550s
   Cloning 'other' took 0.522s
   Cloning 'other' took 0.601s
   Cloning 'other' took 0.480s
   Cloning 'other' took 0.454s
 Total database teardown took 2.556s
 Total run took 40.594s
 }}}

-- 
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/01070183c84f0d39-c35cf2ab-3de7-43c6-b9b7-114b1dc9b1c1-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startproject black   | 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):

 * status:  closed => new
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

 OK, I got it by updating black: `upgraded package black from 21.10b0 to
 22.10.0`

 I'll accept so we can investigate what happened there. 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/01070183c844920a-6860d0d4-9322-482c-82b4-cb4e1a2f2142-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  startproject black   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jeff Triplett):

 Adding my repo in case it's useful: https://github.com/jefftriplett
 /django-startproject#wrench-install

 The repo isn't doing anything fancy but it does have a `requirements.in`
 file that is repeatable.

 {{{
 $ django-admin startproject \
 --extension=ini,py,yml \
 --template=https://github.com/jefftriplett/django-
 startproject/archive/main.zip \
 example_project
 }}}

 *grumble* Please reconsider making assumptions about code formatting based
 on what people have installed globally. We have pre-commit and other tools
 which solve this issue explicitly and have a bit more granularly than
 "just run Black" by default.

-- 
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/01070183c83f7188-435e6d72-9446-4cfc-a5a7-39237a80e290-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  startproject black   | 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:

 Hmm. This doesn't reproduce for me locally, so we're missing something...
 樂

 {{{
 Last login: Tue Oct 11 10:24:11 on ttys000
 carlton@Carltons-MacBook-Pro ~ % mktmpenv
 ...
 (tmp-485998ddadf9b85) carlton@Carltons-MacBook-Pro tmp-485998ddadf9b85 %
 pip install Django
 ...
 Successfully installed Django-4.1.2 asgiref-3.5.2 sqlparse-0.4.3
 (tmp-485998ddadf9b85) carlton@Carltons-MacBook-Pro tmp-485998ddadf9b85 %
 django-admin startproject \
 --extension=ini,py,yml \
 --template=https://github.com/jefftriplett/django-
 startproject/archive/main.zip \
 example_project
 (tmp-485998ddadf9b85) carlton@Carltons-MacBook-Pro tmp-485998ddadf9b85 %
 cat example_project/requirements/requirements.in
 django-click
 Django<4.2
 environs[django]
 psycopg2-binary
 whitenoise

 black
 django-test-plus
 ipdb
 model-bakery
 pip-tools
 pytest
 pytest-cov
 pytest-django
 (tmp-485998ddadf9b85) carlton@Carltons-MacBook-Pro tmp-485998ddadf9b85 %
 black --version
 black, version 21.10b0
 }}}

 Do you think Oliver could dig in a bit to spot where the issue is coming
 up? 樂

 > While I am a fan of Black, I personally think we should have some type
 of --skip-black or --skip-formatters because it's disruptive to have Black
 installed globally and have this be opt-in by default.

 This was discussed (at some length) during the development of the feature.
 It was decided against. Rather set the `PATH` explicitly if you have black
 installed globally but **do not** want to apply it for a particular
 invocation.

-- 
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/01070183c83d4991-f6902649-8d34-4b16-abce-d9735c28e257-00%40eu-central-1.amazonses.com.

Re: [Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
 Reporter:  Jeff Triplett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  startproject black   | 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 Jeff Triplett:

Old description:

> Oliver Andrich on Twitter told me that the `requirements.in` file in my
> startproject was adding spaces after being processed. After a bit more
> digging it appears that Black is being run against non-Python files like
> `requirements.in`, which is a common file pather used with pip-tools and
> pip-compile to create a locked requirements.txt.
> https://twitter.com/oliverandrich/status/1579872988891328513
>
> Ideally, Black should not run on non-Python files  it'd be nice to
> have a better exclude option as Carlton pointed out. See:
> https://twitter.com/carltongibson/status/1579888108010868738

New description:

 Oliver Andrich on Twitter told me that the `requirements.in` file in my
 startproject was adding spaces after being processed. After a bit more
 digging it appears that Black is being run against non-Python files like
 `requirements.in`, which is a common file pather used with pip-tools and
 pip-compile to create a locked requirements.txt.
 https://twitter.com/oliverandrich/status/1579872988891328513

 Ideally, Black should not run on non-Python files  it'd be nice to
 have a better exclude option as Carlton pointed out. See:
 https://twitter.com/carltongibson/status/1579888108010868738

 While I am a fan of Black, I personally think we should have some type of
 `--skip-black` or `--skip-formatters` because it's disruptive to have
 Black installed globally and have this be opt-in by default.

--

-- 
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/01070183c82af3fd-ed4d702b-110d-43e4-9798-d2bfb1c84cd7-00%40eu-central-1.amazonses.com.

[Django] #34085: Black shouldn't format non-Python files

[Django]

#34085: Black shouldn't format non-Python files
-+-
   Reporter:  Jeff   |  Owner:  nobody
  Triplett   |
   Type:  Bug| Status:  new
  Component:  Core   |Version:  4.1
  (Management commands)  |
   Severity:  Normal |   Keywords:  startproject black
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Oliver Andrich on Twitter told me that the `requirements.in` file in my
 startproject was adding spaces after being processed. After a bit more
 digging it appears that Black is being run against non-Python files like
 `requirements.in`, which is a common file pather used with pip-tools and
 pip-compile to create a locked requirements.txt.
 https://twitter.com/oliverandrich/status/1579872988891328513

 Ideally, Black should not run on non-Python files  it'd be nice to
 have a better exclude option as Carlton pointed out. See:
 https://twitter.com/carltongibson/status/1579888108010868738

-- 
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/01070183c823e618-854236f7-bd06-43bf-973e-5f7d395fd81d-00%40eu-central-1.amazonses.com.

Re: [Django] #34084: Regression in Django 4.1 so ModelForms always set self.instance even when none passed in

[Django]

#34084: Regression in Django 4.1 so ModelForms always set self.instance even 
when
none passed in
--+--
 Reporter:  Steven Mapes  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  4.1
 Severity:  Normal|   Resolution:
 Keywords:  modelform | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Steven Mapes):

 * component:  Database layer (models, ORM) => Forms


-- 
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/01070183c819dfb9-ec590bfc-966f-4f53-8790-952d5b010e51-00%40eu-central-1.amazonses.com.

[Django] #34084: Regression in Django 4.1 so ModelForms always set self.instance even when none passed in

[Django]

#34084: Regression in Django 4.1 so ModelForms always set self.instance even 
when
none passed in
-+-
   Reporter:  Steven |  Owner:  nobody
  Mapes  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  modelform
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I came across this bug this morning when running my testsuite against
 Django 3.2, 4.0 and 4.1 (4.1.0, 4.1.1 and 4.1.2).  The issue is with
 ModelForms when they are used without passing in an existing saved
 instance. I thought this was related to the regression that was then fixed
 in 4.1.2 and mentioned in both
 [https://code.djangoproject.com/ticket/33984 33984] and
 [https://code.djangoproject.com/ticket/33952 33952] but the issue is still
 occurring even though both of those are closed.

 To test you can use the below models, form and unit test

 {{{
 # models.py
 from django.db import models


 class Tag(models.Model):
 tag = models.SlugField(max_length=64, unique=True)


 class Thing(models.Model):
 tag = models.ForeignKey(Tag, on_delete=models.CASCADE,
 related_name="things")
 active = models.BooleanField(default=True)

 }}}

 {{{
 # forms.py
 from django import forms
 from example.models import Tag


 class TagForm(forms.ModelForm):
 class Meta:
 model = Tag
 fields = ["tag"]

 def __init__(self, *args, **kwargs):
 super(TagForm, self).__init__(*args, **kwargs)

 if self.instance and self.instance.things:
 inactive_things = self.instance.things.filter(active=False)
 # Do something with it

 }}}


 {{{
 from unittest.case import TestCase
 from example.forms import TagForm


 class TagFormCase(TestCase):
 def test_required(self):
 """Test required fields"""
 form = TagForm({})
 self.assertFalse(form.is_valid())
 self.assertEqual(
 {
 "tag": ["This field is required."],
 },
 form.errors,
 )


 }}}

 If you run the test on Django versions <4.1 including Django 2.*, Django
 3.* and 4.0.* then it'll pass but on 4.1.* it'll fail with ```ValueError:
 'Tag' instance needs to have a primary key value before this relationship
 can be used.```

 In order to pass the if statement needs to be changed to ```if
 self.instance.pk and self.instance.things``` as self.instance is no longer
 None if no instance is passed in.

 If your model uses a custom primary key such as a uuid4 then it'll work as
 expected as the uuid4 is already called

-- 
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/01070183c81702f2-5fb61ab4-7aed-428b-ad2e-9690f2f36400-00%40eu-central-1.amazonses.com.

Re: [Django] #28000: Avoid SET/DROP DEFAULT unless a field changes from null to non-null

[Django]

#28000: Avoid SET/DROP DEFAULT unless a field changes from null to non-null
-+-
 Reporter:  Matteo Pietro Russo  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 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 Alessio Fachechi):

 Replying to [comment:14 Marcin Nowak]:
 > > Django's ORM don't use defaults defined at the database level
 >
 > But it should.
 Totally agree. What's the reason for dropping them? I can understand the
 benefits of making Django handle its own default logic, but that doesn't
 mean dropping the database default, which can be used at last stage. Also
 the Django app is not always the only app accessing and writing to a
 database...

-- 
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/01070183c7773bb2-039dac4c-303f-4a09-89a1-92f42429c625-00%40eu-central-1.amazonses.com.

Re: [Django] #33735: Add asynchronous responses for use with an ASGI server

[Django]

#33735: Add asynchronous responses for use with an ASGI server
+--
 Reporter:  florianvazelle  |Owner:  florianvazelle
 Type:  New feature |   Status:  assigned
Component:  HTTP handling   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI async  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Carlton Gibson):

 * cc: Andrew Godwin, Michael Brown (added)


Comment:

 Hi Florian — Thanks again for this.

 I **finally** got the time to sit with the PR and that for #32798 to try
 and think through the right way forward.

 I'm commenting here, rather than the PR, because I think we need a
 slightly different approach.
 Also cc-ing Andrew and Micheal to ask for their input too.

 So what follows is an RFC...

 Looking at the [https://github.com/django/django/pull/15727 PR here], and
 that for #32798 (either the [https://github.com/django/django/pull/14526
 complex first suggestion], or the
 [https://github.com/django/django/pull/14652 simpler but slower
 alternative]) I think we should consciously opt-out of trying to map
 between sync and async generators. **Maybe** somebody writes a queue
 implementation that has sync one end and async at the other, and handles
 thread-safety, and back-pressure, and who knows what. **Maybe** we could
 use that in Django if we felt it trust-worthy enough. But I don't think we
 should try and write one ourselves.

 Rather, I think we should say that, in the case of streaming responses,
 users need to adjust their code for whether they're planning to run under
 WSGI or ASGI. (We will handle the **other** case both ways, but at a
 performance and memory cost.)

 To wit:

 We add `__aiter__` to `StreamingHttpResponse` and adopt `ASGIHandler` to
 use `async for` in the `if response.streaming` block. Under ASGI you would
 provide `StreamingHttpResponse` with an async iterator, still yielding
 bytestrings as content. This should allow the streaming async responses
 use-case.

 Under WSGI you'd continue to provide a sync iterator and everything would
 work as it is already.

 For each case, `__iter__` and `__aiter__` we handle the **wrong case** by
 consuming the iterator in a single step (using the `asgiref.sync`
 utilities, with `thread_sensitive` for `sync_to_async`) and then yield it
 out in parts as expected. (This is the performance and memory cost.) We
 log a **warning** (that may be filtered in a logging content if not
 desired) saying that folks should use an appropriate generator type in
 this case.

 Note that this is similar to the `__aiter__` implementation on QuerySet,
 which
 
[https://github.com/django/django/blob/f30c7e381c94f41d361877d8a3e90f8cfb391709/django/db/models/query.py#L397-L405
 fetches all the records once inside a single sync_to_async()] to avoid
 multiple (costly) context switches there:

 {{{
 def __aiter__(self):
 # Remember, __aiter__ itself is synchronous, it's the thing it
 returns
 # that is async!
 async def generator():
 await sync_to_async(self._fetch_all)()
 for item in self._result_cache:
 yield item


 return generator()
 }}}

 I think this should be both good enough and maintainable. In the happy
 case, where you provide the right kind of iterator for your chosen
 protocol (ASGI/WSGI) you get the result you want, without us need anything
 overly complex. In the deviant case it'll work (assuming you're not trying
 to stream ''Too much™''). It means we're not branching in the handlers to
 handle each of the different possible iterator types. The abstraction
 leaks a little bit, but I kind of think that's reasonable at this point.

 Maybe: If it proves impossible to get the WSGI+async/ASGI+sync fallback to
 work correctly, just erroring at that point would maybe be acceptable. 樂
 (That you could provide an async iterator to ASGIHandler would allow long-
 lived responses, that aren't currently feasible.)

 Thoughts? Thanks!

 **Assuming** all that makes sense, would you (or Michael maybe) want to
 take this on?
 If not I can pick it up, since it would be good to hit Django 4.2 (feature
 freeze Jan 23) 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 

Re: [Django] #34079: Excessive parentheses when generating a query

[Django]

#34079: Excessive parentheses when generating a query
---+---
 Reporter:  Lelikov|Owner:  Aman Pandey
 Type:  Bug|   Status:  assigned
Component:  Uncategorized  |  Version:  4.1
 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 Aman Pandey):

 * owner:  nobody => Aman Pandey
 * 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/01070183c74ad34d-e72596c3-19f6-4964-94b7-61cb01aa5965-00%40eu-central-1.amazonses.com.

Re: [Django] #34079: Excessive parentheses when generating a query

[Django]

#34079: Excessive parentheses when generating a query
---+--
 Reporter:  Lelikov|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  4.1
 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 Aman Pandey):

 i would like to look into 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/01070183c74ab086-8e413a10-8802-4b66-9acc-63ce0e1a7a27-00%40eu-central-1.amazonses.com.

Re: [Django] #33537: Cloning test databases should reraise errors on MySQL. (was: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server)

[Django]

#33537: Cloning test databases should reraise errors on MySQL.
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.1
  (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 Mariusz Felisiak):

 * type:  Bug => Cleanup/optimization
 * 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/01070183c6fffb82-bc1f2c5d-5a3f-4c75-8bb5-f7746a85eea5-00%40eu-central-1.amazonses.com.

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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 Stephen Finucane):

 Replying to [comment:5 Mariusz Felisiak]:
 > Your issue looks like a misconfiguration and such it is still invalid.
 >
 > Do you want to propose adding `check=True` to subprocess calls and
 change this ticket to a cleanup?

 Yes, exactly (though not with `check=True` as I think that's only
 supported by `subprocess.run`?). I've submitted a patch that should
 address 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/01070183c6fa94e7-24508e90-167d-4931-94fc-751a024d1218-00%40eu-central-1.amazonses.com.

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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 Mariusz Felisiak):

 Your issue looks like a misconfiguration and such it is still invalid.

 Do you want to propose adding `check=True` to subprocess calls and change
 this ticket to a cleanup?

-- 
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/01070183c6f74099-b4a6e442-2e8a-458a-8e9a-7462161b1a1b-00%40eu-central-1.amazonses.com.

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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 Stephen Finucane):

 Reproducing from #34083.

 I'm attempting to run tests in parallel using MariaDB. When running tests,
 all access to the additional databases fail. Scrolling back to the top, I
 see the following error messages:

 {{{
 ❯ tox -e py38-django41 -- patchwork.tests.api.test_user
 patchwork.tests.api.test_event
 py38-django41 run-test-pre: PYTHONHASHSEED='631429049'
 py38-django41 run-test: commands[0] | python
 /home/patchwork/patchwork/manage.py test --noinput --parallel -v 2
 --timing -- patchwork.tests.api.test_user patchwork.tests.api.test_event
 Found 25 test(s).
 Creating test database for alias 'default' ('test_patchwork')...
 Operations to perform:
   Synchronize unmigrated apps: django_filters, humanize, messages,
 rest_framework, staticfiles
   Apply all migrations: admin, auth, authtoken, contenttypes, patchwork,
 sessions, sites
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
 Running migrations:
   Applying contenttypes.0001_initial... OK
   ... {skipped} ...
   Applying sites.0002_alter_domain_unique... OK
 Cloning test database for alias 'default' ('test_patchwork')...
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 Cloning test database for alias 'default' ('test_patchwork')...
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 System check identified no issues (0 silenced).
 ...
 }}}

 The same issue happens on multiple Django versions. With a bit of hacking
 on the code in the tox venv, I was able to inspect the command that Django
 is actually executing:

 {{{
 Dumping! cmd = mysqldump --user=patchwork --host=localhost --routines
 --events test_patchwork
 }}}

 Executing this locally, I see the same issue:

 {{{
 ❯ MYSQL_PWD=password mysqldump --user=patchwork --host=localhost
 --routines --events patchwork
 -- MySQL dump 10.13  Distrib 8.0.30, for Linux (x86_64)
 --
 -- Host: localhostDatabase: patchwork
 -- --
 -- Server version   5.5.5-10.5.16-MariaDB

 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
 /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
 /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
 /*!50503 SET NAMES utf8mb4 */;
 /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
 /*!40103 SET TIME_ZONE='+00:00' */;
 /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
 /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
 FOREIGN_KEY_CHECKS=0 */;
 /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO'
 */;
 /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

 --
 -- Table structure for table `auth_group`
 --

 DROP TABLE IF EXISTS `auth_group`;
 /*!40101 SET @saved_cs_client = @@character_set_client */;
 /*!50503 SET character_set_client = utf8mb4 */;
 CREATE TABLE `auth_group` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `name` varchar(150) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `name` (`name`)
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 /*!40101 SET character_set_client = @saved_cs_client */;

 --
 -- Dumping data for table `auth_group`
 --

 LOCK TABLES `auth_group` WRITE;
 /*!4 ALTER TABLE `auth_group` DISABLE KEYS */;
 /*!4 ALTER TABLE `auth_group` ENABLE KEYS */;
 UNLOCK TABLES;
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema 

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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 Stephen Finucane):

 * version:  3.2 => 4.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/01070183c6e71b73-621536b0-3885-4526-b3ac-f818734d690d-00%40eu-central-1.amazonses.com.

Re: [Django] #33537: Cloning test database fails with mysql-client 8.x and older mysql-server or mariadb-server

[Django]

#33537: Cloning test database fails with mysql-client 8.x and older 
mysql-server or
mariadb-server
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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 Stephen Finucane):

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


Comment:

 Reopening per feedback on #34083

-- 
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/01070183c6e6f176-64bda681-632b-458e-9342-2c7fa44f6960-00%40eu-central-1.amazonses.com.

Re: [Django] #10088: for_share() as well as for_update() addition to Model.QuerySet

[Django]

#10088: for_share() as well as for_update() addition to Model.QuerySet
-+-
 Reporter:  epandurski   |Owner:  xyd
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  select_for_share | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by xyd):

 * status:  new => assigned
 * needs_tests:  0 => 1
 * owner:  (none) => xyd
 * version:  1.0 => dev
 * keywords:   => select_for_share
 * needs_docs:  0 => 1


Comment:

 i am so new , but i want 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/01070183c6dc103c-b31dbe67-a27d-4bc6-8b31-d1c867e5fd3c-00%40eu-central-1.amazonses.com.

Re: [Django] #34083: Cloning test database fails with mariadb-server 8.x

[Django]

#34083: Cloning test database fails with mariadb-server 8.x
-+-
 Reporter:  Stephen Finucane |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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):

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


Comment:

 There is no reason to open a duplicate. Please add a comment to the
 original ticket. Also, I don't think you've explained the issue in enough
 detail to confirm a bug in Django. It looks like a misconfiguration.
 Please reopen the ticket (#33537) if you can debug your issue and provide
 details about why and where Django is at fault.

 We can also consider your suggestion to check if `returncode` is non-zero.
 Personally, I think it makes sense. Please suggest this in the original
 ticket.

 Duplicate of #33537.

-- 
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/01070183c6d48b78-4f56d8af-c5a4-4a90-b2f7-19ecd725bdb3-00%40eu-central-1.amazonses.com.

[Django] #34083: Cloning test database fails with mariadb-server 8.x

[Django]

#34083: Cloning test database fails with mariadb-server 8.x
-+-
   Reporter:  Stephen|  Owner:  nobody
  Finucane   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm attempting to run tests in parallel using MariaDB. When running tests,
 all access to the additional databases fail. Scrolling back to the top, I
 see the following error messages:

 {{{
 ❯ tox -e py38-django41 -- patchwork.tests.api.test_user
 patchwork.tests.api.test_event
 py38-django41 run-test-pre: PYTHONHASHSEED='631429049'
 py38-django41 run-test: commands[0] | python
 /home/patchwork/patchwork/manage.py test --noinput --parallel -v 2
 --timing -- patchwork.tests.api.test_user patchwork.tests.api.test_event
 Found 25 test(s).
 Creating test database for alias 'default' ('test_patchwork')...
 Operations to perform:
   Synchronize unmigrated apps: django_filters, humanize, messages,
 rest_framework, staticfiles
   Apply all migrations: admin, auth, authtoken, contenttypes, patchwork,
 sessions, sites
 Synchronizing apps without migrations:
   Creating tables...
 Running deferred SQL...
 Running migrations:
   Applying contenttypes.0001_initial... OK
   ... {skipped} ...
   Applying sites.0002_alter_domain_unique... OK
 Cloning test database for alias 'default' ('test_patchwork')...
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 Cloning test database for alias 'default' ('test_patchwork')...
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'test_patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)
 System check identified no issues (0 silenced).
 ...
 }}}

 The same issue happens on multiple Django versions. With a bit of hacking
 on the code in the tox venv, I was able to inspect the command that Django
 is actually executing:

 {{{
 Dumping! cmd = mysqldump --user=patchwork --host=localhost --routines
 --events test_patchwork
 }}}

 Executing this locally, I see the same issue:

 {{{
 ❯ MYSQL_PWD=password mysqldump --user=patchwork --host=localhost
 --routines --events patchwork
 -- MySQL dump 10.13  Distrib 8.0.30, for Linux (x86_64)
 --
 -- Host: localhostDatabase: patchwork
 -- --
 -- Server version   5.5.5-10.5.16-MariaDB

 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
 /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
 /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
 /*!50503 SET NAMES utf8mb4 */;
 /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
 /*!40103 SET TIME_ZONE='+00:00' */;
 /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
 /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
 FOREIGN_KEY_CHECKS=0 */;
 /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO'
 */;
 /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

 --
 -- Table structure for table `auth_group`
 --

 DROP TABLE IF EXISTS `auth_group`;
 /*!40101 SET @saved_cs_client = @@character_set_client */;
 /*!50503 SET character_set_client = utf8mb4 */;
 CREATE TABLE `auth_group` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `name` varchar(150) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `name` (`name`)
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 /*!40101 SET character_set_client = @saved_cs_client */;

 --
 -- Dumping data for table `auth_group`
 --

 LOCK TABLES `auth_group` WRITE;
 /*!4 ALTER TABLE `auth_group` DISABLE KEYS */;
 /*!4 ALTER TABLE `auth_group` ENABLE KEYS */;
 UNLOCK TABLES;
 mysqldump: Couldn't execute 'SELECT COLUMN_NAME,
 JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
 FROM information_schema.COLUMN_STATISTICSWHERE SCHEMA_NAME
 = 'patchwork' AND TABLE_NAME = 'auth_group';': Unknown table
 'COLUMN_STATISTICS' in information_schema (1109)

 ❯ echo $?
 2
 }}}

 I'm using Fedora 36 with the default packages:

 {{{
 ❯ cat /etc/system-release
 Fedora release 36 (Thirty Six)

 ❯ sudo dnf list installed | 

Re: [Django] #34059: Validation of check constraints on JSONField key transforms with None produces invalid SQL on PostgreSQL.

[Django]

#34059: Validation of check constraints on JSONField key transforms with None
produces invalid SQL on PostgreSQL.
-+-
 Reporter:  Dan LaManna  |Owner:  David
 |  Sanders
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * type:  Bug => New feature
 * severity:  Release blocker => Normal


-- 
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/01070183c68eed45-e3660ed4-7bd3-455e-9622-94c68d0661b2-00%40eu-central-1.amazonses.com.

Re: [Django] #33952: Too aggressive pk control in create_reverse_many_to_one_manager

[Django]

#33952: Too aggressive pk control in create_reverse_many_to_one_manager
-+-
 Reporter:  Claude Paroz |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Steven Mapes):

 Replying to [comment:8 Claude Paroz]:
 > Many thanks David for the fix!

 Are we sure this is fixed as I still get these errors in all 4.1 versions?
 I posted an example on another ticket, #33984,  which I thought was more
 related to the issue. you can find that report
 [https://code.djangoproject.com/ticket/33984#comment:18 here]

-- 
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/01070183c6824ca3-734c9110-c2ba-4bcc-81e1-8461617f8667-00%40eu-central-1.amazonses.com.

Re: [Django] #33984: Related managers cache gets stale after saving a fetched model with new PK

[Django]

#33984: Related managers cache gets stale after saving a fetched model with new 
PK
-+-
 Reporter:  joeli|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Steven Mapes):

 Replying to [comment:19 Keryn Knight]:
 > Replying to [comment:18 Steven Mapes]:
 > > Is this why model forms now, since Django 4.1.0 raise ValueErrors if
 you try access Related Managers within the `__init__` even if you check
 for the the instance being set along with the relationship?
 >
 > I ''believe'' that's #33952 -- that was fixed in `4.1.1` and this ticket
 in `4.1.2`.

 Ah okay, I just tested it with 3.2.16, 4.0.8, 4.1.0, 4.1.1, 4.1.2 and the
 tests pass in 3.2.16 and 4.0.8 but still fail in the others

-- 
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/01070183c67a7d7a-e1165427-140c-4033-937a-4b6cd34249ff-00%40eu-central-1.amazonses.com.

Re: [Django] #33984: Related managers cache gets stale after saving a fetched model with new PK

[Django]

#33984: Related managers cache gets stale after saving a fetched model with new 
PK
-+-
 Reporter:  joeli|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Keryn Knight):

 Replying to [comment:18 Steven Mapes]:
 > Is this why model forms now, since Django 4.1.0 raise ValueErrors if you
 try access Related Managers within the `__init__` even if you check for
 the the instance being set along with the relationship?

 I ''believe'' that's #33952 -- that was fixed in `4.1.1` and this ticket
 in `4.1.2`.

-- 
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/01070183c662cfa5-c4737ad7-453b-4b33-8409-3a74af922a85-00%40eu-central-1.amazonses.com.

Re: [Django] #33984: Related managers cache gets stale after saving a fetched model with new PK

[Django]

#33984: Related managers cache gets stale after saving a fetched model with new 
PK
-+-
 Reporter:  joeli|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Steven Mapes):

 Is this why model forms now, since Django 4.1.0 raise ValueErrors if you
 try access Related Managers within the __init__ even if you check for the
 the instance being set along with the relationship?

 I.E If you have models and a Model form like this

 {{{
 # models.py
 from django.db import models


 class Tag(models.Model):
 tag = models.SlugField(max_length=64, unique=True)


 class Thing(models.Model):
 tag = models.ForeignKey(Tag, on_delete=models.CASCADE,
 related_name="things")
 active = models.BooleanField(default=True)

 }}}

 {{{
 # forms.py
 from django import forms
 from example.models import Tag


 class TagForm(forms.ModelForm):
 class Meta:
 model = Tag
 fields = ["tag"]

 def __init__(self, *args, **kwargs):
 super(TagForm, self).__init__(*args, **kwargs)

 if self.instance and self.instance.things:
 inactive_things = self.instance.things.filter(active=False)
 # Do something with it

 }}}

 Then have the following test

 {{{
 from unittest.case import TestCase
 from example.forms import TagForm


 class TagFormCase(TestCase):
 def test_required(self):
 """Test required fields"""
 form = TagForm({})
 self.assertFalse(form.is_valid())
 self.assertEqual(
 {
 "tag": ["This field is required."],
 },
 form.errors,
 )


 }}}

 The test would pass in all Django versions up to 4.1. From 4.1.0 onwards
 it raises a ValueError of ```ValueError: 'Tag' instance needs to have a
 primary key value before this relationship can be used.```

 In order for the test to pass you need to change the flow control to ```if
 self.instance.pk and self.instance.things```. You can't use
 ```self.instance.things.count()``` as it raises the exception.

 However if you overload the primary key on the model to use a UUID such
 as:

 {{{
 # models.py
 import uuid
 from django.db import models


 class Tag(models.Model):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 tag = models.SlugField(max_length=64, unique=True)


 class Thing(models.Model):
 tag = models.ForeignKey(Tag, on_delete=models.CASCADE,
 related_name="things")
 active = models.BooleanField(default=True)
 }}}

 then the original test will pass as the uuid will be set prior to saving

-- 
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/01070183c65cce99-7ad7a312-165a-4542-b4d4-cf975cd7fb57-00%40eu-central-1.amazonses.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sébastien Corbin):

 * cc: Sébastien Corbin (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/01070183c606a2eb-81455ce1-7623-47f5-a4a1-2069e87313d6-00%40eu-central-1.amazonses.com.