Re: [Django] #32294: fields.E305 is raised on ManyToManyFields with related_name='+' in models in different apps but with the same name.

[Django]

#32294: fields.E305 is raised on ManyToManyFields with related_name='+' in 
models
in different apps but with the same name.
-+-
 Reporter:  Aleksey Ruban|Owner:  Manav
 |  Agarwal
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13822 PR]

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

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

Re: [Django] #32306: Add decorator django.utils.functional.cached_classproperty

[Django]

#32306: Add decorator django.utils.functional.cached_classproperty
--+
 Reporter:  chessmaster04 |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Utilities |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  cached classproperty  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * cc: Claude Paroz, Simon Charette (added)
 * needs_docs:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepted, but I'm not sure if it's feasible, see Simon's
 [https://code.djangoproject.com/ticket/30864#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/071.c854a3fac0562fc95fcc62a8b875507b%40djangoproject.com.

[Django] #32306: Add decorator django.utils.functional.cached_classproperty

[Django]

#32306: Add decorator django.utils.functional.cached_classproperty
-+-
   Reporter:  Boris  |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Utilities  |Version:  3.1
   Severity:  Normal |   Keywords:  cached
   Triage Stage: |  classproperty
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,
 I propose new decorator "cached_classproperty".
 Django has a lot of methods for caching, like cached_page and
 cached_property.
 Сaching improves response times.
 It was useful for me. I needed to cache the class property because the
 calculation needed to be done on the value.
 What do you think about it?
 https://github.com/django/django/pull/13813

-- 
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/056.a92f125d93d31d66a5561df9070d3106%40djangoproject.com.

Re: [Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
-+
 Reporter:  Adam Hooper  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * cc: Florian Apolloner (added)
 * component:  Core (Other) => contrib.staticfiles
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report, as a workaround you can set the
 [https://docs.djangoproject.com/en/3.1/ref/settings/#force-script-name
 FORCE_SCRIPT_NAME] setting to an empty string:
 {{{#!python
 FORCE_SCRIPT_NAME = ''
 }}}

 Ticket #9202 was rejected and will not be fixed. I think it should be fine
 to add `http://` and `https://` to recognizing absolute paths, e.g.
 {{{
 diff --git a/django/conf/__init__.py b/django/conf/__init__.py
 index 23fee7d5b7..c2ddc942db 100644
 --- a/django/conf/__init__.py
 +++ b/django/conf/__init__.py
 @@ -139,7 +139,7 @@ class LazySettings(LazyObject):
  except (ValidationError, AttributeError):
  pass
  # Don't apply prefix to absolute paths.
 -if value.startswith('/'):
 +if value.startswith(('http://', 'https://', '/')):
  return value
  from django.urls import get_script_prefix
  return '%s%s' % (get_script_prefix(), value)
 }}}

 Florian, What do you think?

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

Re: [Django] #32305: Add an option to limit the number of connections to a database

[Django]

#32305: Add an option to limit the number of connections to a database
-+-
 Reporter:  Barney Szabolcs  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  db connection leak   | 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 Barney Szabolcs:

Old description:

> With the introduction of threads in Django 3.0, somehow only changing
> from Django 2.2.x to Django 3.0 causes the number of connections to build
> up with each request a new connection being added.
> Probably this pile-up is because a bug in one of the django packages.
> However, it would be nice to have a safety feature in Django not to
> exceed a limit of database connections. It would make the whole system a
> lot more robust.
> (At the moment it is not even worth to switch for some long term users
> who use a long list of packages along with Django because the db
> connection buildup has no straightforward solution, yet.)

New description:

 With the introduction of threads in Django 3.0, somehow only changing from
 Django 2.2.x to Django 3.0 causes the number of connections to build up,
 with each request a new connection being added.
 Probably this pile-up is because of some bug in one of the Django-related
 packages. However, it would be nice to have a safety feature in Django not
 to exceed a limit of database connections. It would make the whole system
 a lot more robust.
 (At the moment it is not even worth to switch for some long term users who
 use a long list of packages along with Django because the db connection
 buildup has no straightforward solution, yet.)

--

-- 
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/074.821d1ef17f0b4a0137f0a3ded0880e42%40djangoproject.com.

[Django] #32305: Add an option to limit the number of connections to a database

[Django]

#32305: Add an option to limit the number of connections to a database
-+-
   Reporter:  Barney |  Owner:  nobody
  Szabolcs   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  3.0
  (Other)|
   Severity:  Normal |   Keywords:  db connection leak
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 With the introduction of threads in Django 3.0, somehow only changing from
 Django 2.2.x to Django 3.0 causes the number of connections to build up
 with each request a new connection being added.
 Probably this pile-up is because a bug in one of the django packages.
 However, it would be nice to have a safety feature in Django not to exceed
 a limit of database connections. It would make the whole system a lot more
 robust.
 (At the moment it is not even worth to switch for some long term users who
 use a long list of packages along with Django because the db connection
 buildup has no straightforward solution, yet.)

-- 
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/059.23ec0f991f27f6c2addce68e6ce771cb%40djangoproject.com.

Re: [Django] #32294: fields.E305 is raised on ManyToManyFields with related_name='+' in models in different apps but with the same name.

[Django]

#32294: fields.E305 is raised on ManyToManyFields with related_name='+' in 
models
in different apps but with the same name.
-+-
 Reporter:  Aleksey Ruban|Owner:  Manav
 |  Agarwal
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.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:  1|UI/UX:  0
-+-
Changes (by Manav Agarwal):

 * owner:  nobody => Manav Agarwal
 * status:  new => assigned


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

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

Re: [Django] #25012: Migrations don't make foreign key type changes (was: Migration doesn't seem to detect foreignKey type changes)

[Django]

#25012: Migrations don't make foreign key type changes
-+
 Reporter:  Hedde van der Heide  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Description changed by Tim Graham:

Old description:

> Example:
>
> {{{
> #!div style="font-size: 80%"
> {{{#!python
> class Foo(models.Model):
> id = models.AutoField()  # Now change this to
> models.CharField(primary_key=True, max_length=...) and migrate, the
> migration doesn't complain
>
> class Bar(object):
> foo = models.ForeignKey(Foo)  # but Postgres will still say
> Bar.foo is an Integer value.
> }}}
> }}}
>
> DataError at /myapp/bar/add/
> invalid input syntax for integer: "TEST"
> LINE 1: ...d") VALUES (NULL, 'TEST', ...

New description:

 Example:


 {{{#!python
 class Foo(models.Model):
 id = models.AutoField()  # Now change this to
 models.CharField(primary_key=True, max_length=...) and migrate, the
 migration doesn't complain

 class Bar(object):
 foo = models.ForeignKey(Foo)  # but Postgres will still say Bar.foo is
 an Integer value.
 }}}

 {{{
 DataError at /myapp/bar/add/
 invalid input syntax for integer: "TEST"
 LINE 1: ...d") VALUES (NULL, 'TEST', ...
 }}}

--

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

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

Re: [Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
--+--
 Reporter:  Adam Hooper   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Adam Hooper:

Old description:

> Here's a piece of settings from a totally reasonable, sensible, okay
> Docker integration-test environment
>
> {{{
> STATIC_URL = "http://minio/static/";
> }}}
>
> Django 3.1 will implicitly add "/" to the URL, so my URLs look like
> ""/http://minio/static/images/app-icons/favicon.ico";.
>
> The features and bugs that interact here:
>
> * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
> STATIC_URL when STATIC_URL isn't a URL.
> * bug #9202 and #25418: according to Django, "http://minio/static/"; isn't
> a valid URL. (It is.)
>
> Top me, the easiest fix is to address #9202 / #25418. Or to make
> `STATIC_URL` use some logic that is different from URLValidator.

New description:

 Here's a piece of settings from a totally reasonable, sensible, okay
 Docker integration-test environment

 {{{
 STATIC_URL = "http://minio/static/";
 }}}

 Django 3.1 will implicitly add "/" to the URL, so my URLs look like
 {{{/http://minio/static/images/app-icons/favicon.ico}}}

 The features and bugs that interact here:

 * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
 STATIC_URL when STATIC_URL isn't a URL.
 * bug #9202 and #25418: according to Django, "http://minio/static/"; isn't
 a valid URL. (It is.)

 Top me, the easiest fix is to address #9202 / #25418. Or to make
 `STATIC_URL` use some logic that is different from URLValidator.

--

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

Re: [Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
--+--
 Reporter:  Adam Hooper   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Adam Hooper):

 My workaround was to create a phony URL and point to it in
 {{{/etc/hosts}}}.

 Yes, really.
 
https://github.com/CJWorkbench/cjworkbench/commit/6aec10f441f5392bda7df247cddc8828b52a0c84

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

Re: [Django] #32302: Permit migrations in non-namespace packages that don't have __file__

[Django]

#32302: Permit migrations in non-namespace packages that don't have __file__
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migrations freezers  | 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 William Schwartz):

 == Appendix: Research Notes

 'This ticket is closed. You need read no further unless you're
 researching a different issue related to the Python import system or
 Django's migration loading.'

 While doing my research this ticket, I took a lot of notes that didn't
 make it into the actual report. Here they are, in case it helps someone
 else down the line.

 === More background on `__file__`

 `__file__` is set by the import machinery from
 
[https://docs.python.org/3.9/library/importlib.html#importlib.machinery.ModuleSpec.origin
 importlib.machinery.ModuleSpec.origin], which may be `None`:

 > Name of the place from which the module is loaded, e.g. “builtin” for
 built-in modules and the filename for modules loaded from source. Normally
 “origin” should be set, but it may be None (the default) which indicates
 it is unspecified (e.g. for namespace packages).

 One frozen Python environment, PyOxidizer,
 
[https://pyoxidizer.readthedocs.io/en/stable/oxidized_importer_behavior_and_compliance.html
 #file-and-cached-module-attributes relies] on this API rule.

 === Proving a module is a namespace package

 [https://docs.python.org/3.9/whatsnew/3.7.html#other-cpython-
 implementation-changes Since Python 3.7] fixed
 [https://bugs.python.org/issue32303 bpo-32303], it is no longer possible
 to prove definitively that a module is a namespace package. In Python 3.6
 and earlier, a module's
 [https://docs.python.org/3.9/reference/import.html#__loader__ __loader__]
 was `None` if and only if the module was a namespace package. This was
 because [https://www.python.org/dev/peps/pep-0451/#namespace-packages PEP
 451] required that a [https://docs.python.org/3.9/glossary.html#term-
 finder finder]'s
 
[https://docs.python.org/3.9/library/importlib.html#importlib.abc.MetaPathFinder.find_spec
 find_spec] set
 
[https://docs.python.org/3.9/library/importlib.html#importlib.machinery.ModuleSpec.loader
 loader] to `None`:

 > Currently a path entry finder may return (None, portions) from
 
[https://docs.python.org/3.9/library/importlib.html#importlib.abc.PathEntryFinder.find_loader
 find_loader()] to indicate it found part of a possible namespace package.
 To achieve the same effect, find_spec() must return a spec with "loader"
 set to None (a.k.a. not set) and with submodule_search_locations set

 In Python 3.9, calling
 [https://docs.python.org/3.9/library/importlib.html#importlib.util.find_spec
 importlib.util.find_spec] on the name of a not-yet-imported namespace
 package returned a spec whose `loader` is `None`, but once the module is
 imported, the returned spec's `loader` is an instance of
 `_frozen_importlib_external._NamespaceLoader`. Note that
 `_NamespaceLoader` is an implementation detail of CPython.

 We must resist the temptation to rely on Python's
 [https://docs.python.org/3.9/reference/import.html#loading documented code
 for detecting namespace packages]:

 > {{{#!python
 > if spec.origin is None and spec.submodule_search_locations is not None:
 > # namespace package
 > sys.modules[spec.name] = module
 > }}}

 This documentation is patently falsified by a cursory review of Python's
 
[https://github.com/python/cpython/blob/4140f10a16f06c32fd49f9e21fb2a53abe7357f0/Lib/importlib/_bootstrap.py#L511-L538
 source code], which clearly relies on `loader` being `None`.

 See also [https://www.python.org/dev/peps/pep-0420/#differences-between-
 namespace-packages-and-regular-packages PEP-420's summary of differences
 between namespace and regular packages], which is now somewhat outdated.

 === History of the migration loader's no-namespace check

 The reason, given both in the
 
[https://github.com/django/django/blob/2a76f4313423a3b91caade4fce71790630ef9152/django/db/migrations/loader.py#L91-L95
 source code comments] and in [https://groups.google.com/g/django-
 developers/c/GVHMH2ciAnk/m/vbIPbZuSBQAJ discussions among maintainers],
 for the migration loader's check that an app's `migrations` package is not
 a namespace package is to discourage the latter's use.

 The current name

Re: [Django] #32303: Drop support for SQLite < 3.9.0

[Django]

#32303: Drop support for SQLite < 3.9.0
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Tim Graham):

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

Re: [Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
--+--
 Reporter:  Adam Hooper   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Adam Hooper:

Old description:

> Here's a piece of settings from a totally reasonable, sensible, okay
> Docker integration-test environment
>
> {{{
> STATIC_URL = "http://minio/static/";
> }}}
>
> Django 3.1 will implicitly add "/" to the URL, so my URLs look like
> ""/http://minio/static/images/app-icons/favicon.ico";.
>
> The features and bugs that interact here:
>
> * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
> STATIC_URL when STATIC_URL isn't a URL.
> * bug #9202 and #25418: according to Django, "http://minio/static/"; isn't
> a valid URL. (It is.)
>
> Top me, the easiest fix is to address #9202 / #25418

New description:

 Here's a piece of settings from a totally reasonable, sensible, okay
 Docker integration-test environment

 {{{
 STATIC_URL = "http://minio/static/";
 }}}

 Django 3.1 will implicitly add "/" to the URL, so my URLs look like
 ""/http://minio/static/images/app-icons/favicon.ico";.

 The features and bugs that interact here:

 * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
 STATIC_URL when STATIC_URL isn't a URL.
 * bug #9202 and #25418: according to Django, "http://minio/static/"; isn't
 a valid URL. (It is.)

 Top me, the easiest fix is to address #9202 / #25418. Or to make
 `STATIC_URL` use some logic that is different from URLValidator.

--

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

Re: [Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
--+--
 Reporter:  Adam Hooper   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Adam Hooper:

Old description:

> Here's a piece of settings from a totally reasonable, sensible, okay
> Docker integration-test environment
>
> {{{
> STATIC_URL = "http://minio/static/";
> }}}
>
> Django 3.1 will implicitly add "/" to the URL, so my URLs look like
> ""/http://minio/static/images/app-icons/favicon.ico";.
>
> The features and bugs that interact here:
>
> * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
> STATIC_URL when STATIC_URL isn't a URL.
> * bug #9202: according to Django, "http://minio/static/"; isn't a valid
> URL. (It is.)
>
> Top me, the easiest fix is to address #9202

New description:

 Here's a piece of settings from a totally reasonable, sensible, okay
 Docker integration-test environment

 {{{
 STATIC_URL = "http://minio/static/";
 }}}

 Django 3.1 will implicitly add "/" to the URL, so my URLs look like
 ""/http://minio/static/images/app-icons/favicon.ico";.

 The features and bugs that interact here:

 * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
 STATIC_URL when STATIC_URL isn't a URL.
 * bug #9202 and #25418: according to Django, "http://minio/static/"; isn't
 a valid URL. (It is.)

 Top me, the easiest fix is to address #9202 / #25418

--

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

[Django] #32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/"

[Django]

#32304: Django adds spurious "/" prefix to settings.STATIC_URL="http://server/";
+
   Reporter:  Adam Hooper   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Other)  |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Here's a piece of settings from a totally reasonable, sensible, okay
 Docker integration-test environment

 {{{
 STATIC_URL = "http://minio/static/";
 }}}

 Django 3.1 will implicitly add "/" to the URL, so my URLs look like
 ""/http://minio/static/images/app-icons/favicon.ico";.

 The features and bugs that interact here:

 * commit c574bec, adding feature #25598, prepends SCRIPT_NAME to
 STATIC_URL when STATIC_URL isn't a URL.
 * bug #9202: according to Django, "http://minio/static/"; isn't a valid
 URL. (It is.)

 Top me, the easiest fix is to address #9202

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

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

Re: [Django] #10070: Named parameters not working on raw sql queries with sqlite

[Django]

#10070: Named parameters not working on raw sql queries with sqlite
-+-
 Reporter:  Matias Surdi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Charlie DeTar):

 I encountered a use case where I wanted to do an upsert query (`INSERT ...
 ON CONFLICT DO UPDATE SET ...`).  This is raw SQL that is not supported by
 the ORM, but has consistent syntax between sqlite and postgresql.  I ran
 into this trouble with named parameters.  The query syntax itself worked
 for both backends, but the parameter naming syntax did not.  I worked
 around this by just using positional arguments instead -- but there are
 valid needs for raw SQL targeting more than one database backend, and
 consistent named parameter syntax would be useful.

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

Re: [Django] #25012: Migration doesn't seem to detect foreignKey type changes

[Django]

#25012: Migration doesn't seem to detect foreignKey type changes
-+
 Reporter:  Hedde van der Heide  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Paul Schreiber):

 I ran in to this today (Django 3.1.4). The workaround was to
 {{{
 UPDATE myapp.mytable set my_fk_column = NULL;
 }}}
 and re-run the migration.

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

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

Re: [Django] #32297: QuerySet.get() method not working as expected with Window functions

[Django]

#32297: QuerySet.get() method not working as expected with Window functions
-+-
 Reporter:  Jerin Peter George   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 It's just how window functions behave when mixed with a query level
 constraint (`WHERE`) or `LIMIT`'ing;

 In your first example the `[:10]` performs a `LIMIT 10` so the `RANK` will
 be over ten results while `get(pk=1442)` will be against in a single
 result through `WHERE id = 1442 LIMIT 21`.

 To me this is a similar class of problem to #24462, #28333. If it was
 possible to use the current result set as a subquery then the following
 would work as expected

 {{{#!python
 Task.objects.annotate(
 rank=Window(expression=Rank(), order_by=F('logged').desc())
 )[0:10].subquery().get(pk=1442)
 }}}

 As it would result in

 {{{#!sql
 SELECT * FROM (
 SELECT task.*, RANK() OVER (ORDER BY logged DESC) AS "rank"
 FROM task
 LIMIT 10
 ) subquery WHERE id=1442 LIMIT 21
 }}}

 Where the window function would span over the full ten set of rows.

 Whether or not `get` should do the subquery pushdown automatically is
 debatable. I get a feeling it should as the fact it uses `LIMIT` is more
 of an implementation detail but it would be slightly backward
 incompatible.

-- 
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/074.e328c79d8309ff8dcf5b807905fe1c87%40djangoproject.com.

Re: [Django] #32303: Drop support for SQLite < 3.9.0

[Django]

#32303: Drop support for SQLite < 3.9.0
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13821 PR]

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

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

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Pavel
 Type:   |  Druzhinin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 Thanks for this patch, however it's not ready for review. Please fix tests
 and `isort`.

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

Re: [Django] #32302: Permit migrations in non-namespace packages that don't have __file__

[Django]

#32302: Permit migrations in non-namespace packages that don't have __file__
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migrations freezers  | 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 ):

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


Comment:

 In [changeset:"e64c1d8055a3e476122633da141f16b50f0c4a2d" e64c1d80]:
 {{{
 #!CommitTicketReference repository=""
 revision="e64c1d8055a3e476122633da141f16b50f0c4a2d"
 Fixed #32302 -- Allowed migrations to be loaded from regular packages with
 no __file__ attribute.

 The migrations loader prevents the use of PEP-420 namespace packages
 for holding apps' migrations modules. Previously the loader tested for
 this only by checking that app.migrations.__file__ is present. This
 prevented migrations' being found in frozen Python environments that
 don't set __file__ on any modules. Now the loader *additionally* checks
 whether app.migrations.__path__ is a list because namespace packages
 use a different type for __path__. Namespace packages continue to be
 forbidden, and, in fact, users of normal Python environments should
 experience no change whatsoever.
 }}}

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

Re: [Django] #32303: Drop support for SQLite < 3.9.0

[Django]

#32303: Drop support for SQLite < 3.9.0
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Old description:

> Indexes on expressions (see #26167) and the `SQLITE_ENABLE_JSON1`
> compile-time option are supported on
> [https://sqlite.org/changes.html#version_3_9_0 SQLite 3.9.0+].
>
> Ubuntu Xenial ships with SQLite 3.11.0 and will EOL in April 2021.
>
> SQLite 3.9.0 was released in October 2015. SQLite version support seems
> like a similar situation as GEOS libraries which we generally support
> about 5 years after released.

New description:

 Indexes on expressions (see #26167) and the `SQLITE_ENABLE_JSON1` compile-
 time option are supported on
 [https://sqlite.org/changes.html#version_3_9_0 SQLite 3.9.0+].

 Ubuntu Xenial ships with SQLite 3.11.0 (which will still by supported by
 Django) and will EOL in April 2021. Debian Jessie ships with 3.8.7 and was
 EOL June 30, 2020.

 SQLite 3.9.0 was released in October 2015. SQLite version support seems
 like a similar situation as GEOS libraries which we generally support
 about 5 years after released.

--

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

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Pavel
 Type:   |  Druzhinin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Pavel Druzhinin):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 PR has been updated https://github.com/django/django/pull/13784

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

Re: [Django] #25916: Add lastmod support to sitemapindex

[Django]

#25916: Add lastmod support to sitemapindex
--+---
 Reporter:  Matthew Downey|Owner:  David Smith
 Type:  New feature   |   Status:  assigned
Component:  contrib.sitemaps  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  sitemap lastmod   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by David Smith):

 * owner:  Matthew Downey => David Smith


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

Re: [Django] #32303: Drop support for SQLite < 3.9.0

[Django]

#32303: Drop support for SQLite < 3.9.0
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  3.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 Mariusz Felisiak):

 * cc: Tim Graham (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/065.38b4474f98e80c0cc8ff45fa7188599e%40djangoproject.com.

[Django] #32303: Drop support for SQLite < 3.9.0

[Django]

#32303: Drop support for SQLite < 3.9.0
-+-
   Reporter:  Mariusz|  Owner:  Mariusz Felisiak
  Felisiak   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  3.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  |
-+-
 Indexes on expressions (see #26167) and the `SQLITE_ENABLE_JSON1` compile-
 time option are supported on
 [https://sqlite.org/changes.html#version_3_9_0 SQLite 3.9.0+].

 Ubuntu Xenial ships with SQLite 3.11.0 and will EOL in April 2021.

 SQLite 3.9.0 was released in October 2015. SQLite version support seems
 like a similar situation as GEOS libraries which we generally support
 about 5 years after released.

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

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

Re: [Django] #19580: Unify reverse foreign key and m2m unsaved model querying

[Django]

#19580: Unify reverse foreign key and m2m unsaved model querying
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Pavel
 Type:   |  Druzhinin
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Pavel Druzhinin):

 Rebased the previous PR https://github.com/django/django/pull/11807.
 I would like to get some clarification on this old ticket, took it under
 easy-pickings tag.

 https://github.com/django/django/pull/11807#pullrequestreview-344544165 -
 this is the last comment from where I started to search next steps to
 complete the ticket.
 It leads to the undone comments:

 1. https://github.com/django/django/pull/8570#pullrequestreview-113177526
 Should I move all tests from m2m_through_regress to many_to_many or some
 particular tests?

 2. https://github.com/django/django/pull/8570#pullrequestreview-113506649
 I see prepared changelogs in comment
 https://github.com/django/django/pull/11807#issuecomment-612404721, but
 don't know where to place them in codebase. Could you explain?

 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/066.15e193518a566e13299f1f1552d8b1ce%40djangoproject.com.

Re: [Django] #32297: QuerySet.get() method not working as expected with Window functions

[Django]

#32297: QuerySet.get() method not working as expected with Window functions
-+-
 Reporter:  Jerin Peter George   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Mariusz Felisiak, Simon Charette (added)
 * stage:  Unreviewed => Accepted


Comment:

 I'm going to provisionally accept this and ask Simon and Mariusz to have a
 look, since there does seem to be something amiss.

 Taking a similar case from one of my own projects, it's not just `values`
 (which
 [https://docs.djangoproject.com/en/3.1/topics/db/aggregation/#values might
 be/have been the issue]) the shows the strange behaviour, but straight
 iteration:

 {{{
 >>> list((t.pk, t.rank) for t in
 Task.objects.annotate(rank=Window(expression=Rank(),
 order_by=F("logged").desc()))[:10])
 [(1444, 1), (1443, 2), (1442, 3), (1441, 4), (1440, 5), (1439, 6), (1438,
 7), (1437, 8), (1436, 9), (1435, 10)]
 >>> Task.objects.annotate(rank=Window(expression=Rank(),
 order_by=F("logged").desc())).get(pk=1444).rank
 1
 >>> Task.objects.annotate(rank=Window(expression=Rank(),
 order_by=F("logged").desc())).get(pk=1442).rank
 1
 }}}

 I'm very much expecting the last line there to output 3.

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

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

Re: [Django] #26602: Provide a way to manage grouping with RawSQL

[Django]

#26602: Provide a way to manage grouping with RawSQL
-+-
 Reporter:  Jamie Cockburn   |Owner:  Manav
 |  Agarwal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by Claude Paroz):

 Awesome! I'll let a fellow decide if it's worth adding a new regression
 test or if this issue can be closed right now.

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

Re: [Django] #32299: MiddlewareNotUsed leaves undesired side effects when loading middleware in ASGI context

[Django]

#32299: MiddlewareNotUsed leaves undesired side effects when loading middleware 
in
ASGI context
-+-
 Reporter:  Hubert Bielenia  |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 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 Mariusz Felisiak ):

 In [changeset:"6b4b7da740cea6d1fc7ae7028a357587f3e9d0b3" 6b4b7da7]:
 {{{
 #!CommitTicketReference repository=""
 revision="6b4b7da740cea6d1fc7ae7028a357587f3e9d0b3"
 [3.1.x] Fixed #32299 -- Prevented mutating handlers when processing
 middlewares marking as unused in an async context.

 Thanks Hubert Bielenia for the report.
 Backport of 98ad327864aed8df245fd19ea9d2743279e11643 from master
 }}}

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

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

Re: [Django] #32299: MiddlewareNotUsed leaves undesired side effects when loading middleware in ASGI context

[Django]

#32299: MiddlewareNotUsed leaves undesired side effects when loading middleware 
in
ASGI context
-+-
 Reporter:  Hubert Bielenia  |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 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
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"98ad327864aed8df245fd19ea9d2743279e11643" 98ad327]:
 {{{
 #!CommitTicketReference repository=""
 revision="98ad327864aed8df245fd19ea9d2743279e11643"
 Fixed #32299 -- Prevented mutating handlers when processing middlewares
 marking as unused in an async context.

 Thanks Hubert Bielenia for the report.
 }}}

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

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