Re: [Django] #32673: Nested Q() objects raises ProgrammingError on PostgreSQL and Oracle. (was: ProgrammingError resulting from invalid SQL for nested models.Q instances)

[Django]

#32673: Nested Q() objects raises ProgrammingError on PostgreSQL and Oracle.
-+-
 Reporter:  Charles Lirsac   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql oracle q  | 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: Simon Charette (added)
 * keywords:   => postgresql oracle q
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report.

 Regression in 3a505c70e7b228bf1212c067a8f38271ca86ce09.
 Reproduced at 6d0cbe42c3d382e5393d4af48185c546bb0ada1f.

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

Re: [Django] #32673: ProgrammingError resulting from invalid SQL for nested models.Q instances

[Django]

#32673: ProgrammingError resulting from invalid SQL for nested models.Q 
instances
-+-
 Reporter:  Charles Lirsac   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by Charles Lirsac:

Old description:

> Given the following model:
>
> {{{
> class Price(models.Model):
> price = models.IntegerField(null=False)
> price_previous = models.IntegerField(null=False)
> on_sale = models.BooleanField(null=False)
> }}}
>
> The following query used to work in 2.2. but emits a `ProgrammingError`
> on 3.0+ against a Postgres database:
>
> {{{
> Price.objects.filter(
> models.Q(
> on_sale=models.ExpressionWrapper(
> models.Q(price__lt=models.F('price_previous')),
> output_field=models.BooleanField(),
> )
> )
> )
> }}}
>
> Traceback:
>
> {{{
> Traceback (most recent call last):
>   File "", line 5, in 
>   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
> 256, in __repr__
> data = list(self[:REPR_OUTPUT_SIZE + 1])
>   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
> 280, in __iter__
> self._fetch_all()
>   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
> 1324, in _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
> 51, in __iter__
> results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
> chunk_size=self.chunk_size)
>   File ".../lib/python3.7/site-
> packages/django/db/models/sql/compiler.py", line 1169, in execute_sql
> cursor.execute(sql, params)
>   File ".../lib/python3.7/site-packages/django/db/backends/utils.py",
> line 98, in execute
> return super().execute(sql, params)
>   File ".../lib/python3.7/site-packages/django/db/backends/utils.py",
> line 66, in execute
> return self._execute_with_wrappers(sql, params, many=False,
> executor=self._execute)
>   File ".../lib/python3.7/site-packages/django/db/backends/utils.py",
> line 75, in _execute_with_wrappers
> return executor(sql, params, many, context)
>   File ".../lib/python3.7/site-packages/django/db/backends/utils.py",
> line 84, in _execute
> return self.cursor.execute(sql, params)
>   File ".../lib/python3.7/site-packages/django/db/utils.py", line 90, in
> __exit__
> raise dj_exc_value.with_traceback(traceback) from exc_value
>   File ".../lib/python3.7/site-packages/django/db/backends/utils.py",
> line 84, in _execute
> return self.cursor.execute(sql, params)
> django.db.utils.ProgrammingError: syntax error at or near "<"
> LINE 1: ..."prices_price"."on_sale" = "prices_price"."price" <
> "prices_...
> }}}
>
> The error comes from the way the query ended up compiled, in 3.2 we get:
>
> {{{
> SELECT "prices_price"."id", "prices_price"."price",
> "prices_price"."price_previous", "prices_price"."on_sale"
> FROM "prices_price"
> WHERE "prices_price"."on_sale" = "prices_price"."price" <
> "prices_price"."price_previous"
> }}}
>
> The right hand side of the clause is not wrapped in parentheses. While on
> 2.2 we get:
>
> {{{
> SELECT "prices_price"."id", "prices_price"."price",
> "prices_price"."price_previous", "prices_price"."on_sale"
> FROM "prices_price"
> WHERE "prices_price"."on_sale" = ("prices_price"."price" <
> ("prices_price"."price_previous"))
> }}}
>
> The right hand side is correctly wrapped.
>
> Sorry if the title is not super accurate, I wasn't sure how to exactly to
> describe the exact kind of models.Q invocation at play here.
>
> Versions:
>
> - Python 3.7
> - Tested agains postgres 9.6, 11 and 13
> - Tested against 3.0.14, 3.1.8 and 3.2. It works on 2.2.20
>
> For reference. the following query (valid in 3.0+) is equivalent and
> generates the same broken SQL:
>
> {{{
> Price.objects.filter(
> models.Q(
> on_sale=models.Q(price__lt=models.F('price_previous'))
> )
> )
> }}}
>
> I've logged more details and a complete reproduction at
> https://github.com/lirsacc/django-check-constraint-pg-regression (in the
> context of a `CheckConstraint` and migrations which is where we first saw
> this).

New description:

 Given the following model:

 {{{
 class Price(models.Model):
 price = models.IntegerField(null=False)
 price_previous = 

[Django] #32673: ProgrammingError resulting from invalid SQL for nested models.Q instances

[Django]

#32673: ProgrammingError resulting from invalid SQL for nested models.Q 
instances
-+-
   Reporter:  Charles|  Owner:  nobody
  Lirsac |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  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  |
-+-
 Given the following model:

 {{{
 class Price(models.Model):
 price = models.IntegerField(null=False)
 price_previous = models.IntegerField(null=False)
 on_sale = models.BooleanField(null=False)
 }}}

 The following query used to work in 2.2. but emits a `ProgrammingError` on
 3.0+ against a Postgres database:

 {{{
 Price.objects.filter(
 models.Q(
 on_sale=models.ExpressionWrapper(
 models.Q(price__lt=models.F('price_previous')),
 output_field=models.BooleanField(),
 )
 )
 )
 }}}

 Traceback:

 {{{
 Traceback (most recent call last):
   File "", line 5, in 
   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
 256, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
 280, in __iter__
 self._fetch_all()
   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
 1324, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File ".../lib/python3.7/site-packages/django/db/models/query.py", line
 51, in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File ".../lib/python3.7/site-packages/django/db/models/sql/compiler.py",
 line 1169, in execute_sql
 cursor.execute(sql, params)
   File ".../lib/python3.7/site-packages/django/db/backends/utils.py", line
 98, in execute
 return super().execute(sql, params)
   File ".../lib/python3.7/site-packages/django/db/backends/utils.py", line
 66, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File ".../lib/python3.7/site-packages/django/db/backends/utils.py", line
 75, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File ".../lib/python3.7/site-packages/django/db/backends/utils.py", line
 84, in _execute
 return self.cursor.execute(sql, params)
   File ".../lib/python3.7/site-packages/django/db/utils.py", line 90, in
 __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File ".../lib/python3.7/site-packages/django/db/backends/utils.py", line
 84, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: syntax error at or near "<"
 LINE 1: ..."prices_price"."on_sale" = "prices_price"."price" < "prices_...
 }}}

 The error comes from the way the query ended up compiled, in 3.2 we get:

 {{{
 SELECT "prices_price"."id", "prices_price"."price",
 "prices_price"."price_previous", "prices_price"."on_sale"
 FROM "prices_price"
 WHERE "prices_price"."on_sale" = "prices_price"."price" <
 "prices_price"."price_previous"
 }}}

 The right hand side of the clause is not wrapped in parentheses. While on
 2.2 we get:

 {{{
 SELECT "prices_price"."id", "prices_price"."price",
 "prices_price"."price_previous", "prices_price"."on_sale"
 FROM "prices_price"
 WHERE "prices_price"."on_sale" = ("prices_price"."price" <
 ("prices_price"."price_previous"))
 }}}

 The right hand side is correctly wrapped.

 Sorry if the title is not super accurate, I wasn't sure how to exactly to
 describe the exact kind of models.Q invocation at play here.

 Versions:

 - Python 3.7
 - Tested agains postgres 9.6, 11 and 13
 - Tested against 3.0.14, 3.1.8 and 3.2. It works on 2.2.20

 For reference. the following query (valid in 3.0+) is equivalent and
 generates the same broken SQL:

 {{{
 Price.objects.filter(
 models.Q(
 on_sale=models.Q(price__lt=models.F('price_previous'))
 )
 )
 }}}

 I've logged more details and a complete reproduction at
 https://github.com/lirsacc/django-check-constraint-pg-regression (in the
 context of a `CheckConstraint` and migrations which is where we first saw
 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 

Re: [Django] #32672: Primary Key, type double and type unsigned integer ain't detected correctly for Sqlite3 Database

[Django]

#32672: Primary Key, type double and type unsigned integer ain't detected 
correctly
for Sqlite3 Database
-+-
 Reporter:  jgr88|Owner:  jgr88
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  SQLite3 PrimaryKey   | Triage Stage:
  Datatypes  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by jgr88):

 Replying to [ticket:32672 jgr88]:
 > While creating models with "inspectdb" i discovered, that there are
 currently some issues with SQLite3 Databases.
 > - PrimaryKeys ain't detected properly
 > - Datatype double ain't detected properly
 > - Datatype unsigned int ain't detected properly
 >
 > Reproduce these issues by creating a SQLite3 Database:
 > CREATE TABLE "test" ( `pId` INTEGER NOT NULL, `doubleField` DOUBLE NOT
 NULL, `uInt` UNSIGNED INTEGER NOT NULL, PRIMARY KEY(`pId`) )
 >
 > I added a pullrequest:
 > https://github.com/django/django/pull/14293

 Update:
 I added [https://github.com/django/django/pull/14297] since i messed up
 the first one

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

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

Re: [Django] #32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2

[Django]

#32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2
-+-
 Reporter:  Jan Pieter   |Owner:  Florian
  Waagmeester|  Apolloner
 Type:  Bug  |   Status:  closed
Component:  contrib.messages |  Version:  3.2
 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 Florian Apolloner):

 > and there is no workaround until 3.2.1 is released, right?

 Setting a custom storage backend with the fix applied is one option. The
 other option is a custom Django package till 3.2.1 is 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/064.2bd97604ea76dec7b8ddb5b0adb7095f%40djangoproject.com.

Re: [Django] #32672: Primary Key, type double and type unsigned integer ain't detected correctly for Sqlite3 Database

[Django]

#32672: Primary Key, type double and type unsigned integer ain't detected 
correctly
for Sqlite3 Database
-+-
 Reporter:  jgr88|Owner:  jgr88
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  SQLite3 PrimaryKey   | Triage Stage:
  Datatypes  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Girish Sontakke):

 * owner:  nobody => jgr88
 * 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/073.584925e46c1ff63cdc4f87063094ebf8%40djangoproject.com.

Re: [Django] #16055: Filtering over generic relations with TextField/CharField object_id breaks in postgres

[Django]

#16055: Filtering over generic relations with TextField/CharField object_id 
breaks
in postgres
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  3.2
 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 Marc DEBUREAUX):

 * cc: Marc DEBUREAUX (added)
 * version:  1.3 => 3.2


Comment:

 Change Django version number for visibility purposes.

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

Re: [Django] #32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2

[Django]

#32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2
-+-
 Reporter:  Jan Pieter   |Owner:  Florian
  Waagmeester|  Apolloner
 Type:  Bug  |   Status:  closed
Component:  contrib.messages |  Version:  3.2
 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 Adam Hooper):

 Could Django please release a patch release that fixes this bug?

 Unless I'm misunderstanding, I've run into this:

 1. Upgrade to Django 3.2.
 2. Test. Everything passes.
 3. Deploy to production.
 4. Users experience 500 errors.

 In my case, I _happened_ to catch this when I deployed to staging. Pure
 luck.

 But in general, this crash affect tons of existing sites and there is no
 workaround until 3.2.1 is released, right?

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

Re: [Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
--+
 Reporter:  Abhyudai  |Owner:  Abhyudai
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (System checks)  |  Version:  3.2
 Severity:  Normal|   Resolution:  fixed
 Keywords:  documentation | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"7d7c6d9a3a75f7e0dfe1e7fb992e3c3a6068a87e" 7d7c6d9]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d7c6d9a3a75f7e0dfe1e7fb992e3c3a6068a87e"
 [3.2.x] Fixed #32667 -- Added link to labeling checks in
 BaseCommand.requires_system_checks docs.

 Co-authored-by: Mariusz Felisiak 
 Backport of 4a77aeb1f86bc06e18023cac10109e067ed20800 from main
 }}}

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

Re: [Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
--+
 Reporter:  Abhyudai  |Owner:  Abhyudai
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (System checks)  |  Version:  3.2
 Severity:  Normal|   Resolution:  fixed
 Keywords:  documentation | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by GitHub ):

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


Comment:

 In [changeset:"4a77aeb1f86bc06e18023cac10109e067ed20800" 4a77aeb1]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a77aeb1f86bc06e18023cac10109e067ed20800"
 Fixed #32667 -- Added link to labeling checks in
 BaseCommand.requires_system_checks docs.

 Co-authored-by: Mariusz Felisiak 
 }}}

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

Re: [Django] #32662: Refactor a generator out from part of SQLCompiler.get_order_by()

[Django]

#32662: Refactor a generator out from part of SQLCompiler.get_order_by()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"0461b7a6b62a5acd0db47f8dd76f3dfe7c62b0f5" 0461b7a6]:
 {{{
 #!CommitTicketReference repository=""
 revision="0461b7a6b62a5acd0db47f8dd76f3dfe7c62b0f5"
 Fixed #32662 -- Refactored a generator out of SQLCompiler.get_order_by().

 This also renames the `asc` variable to `default_order`, markes the
 `desc` variable as unused, fixes a typo in SQLCompiler.get_order_by()
 docstring, and reorders some blocks in SQLCompiler._order_by_pairs().
 }}}

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

Re: [Django] #28628: Audit for and abolish all use of '\d' in regexes

[Django]

#28628: Audit for and abolish all use of '\d' in regexes
--+
 Reporter:  James Bennett |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+
Changes (by Sergey Fedoseev):

 * cc: Sergey Fedoseev (removed)


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

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

Re: [Django] #32669: Allow autoreloading of `python -m custom_module runserver`

[Django]

#32669: Allow autoreloading of `python -m custom_module runserver`
-+-
 Reporter:  Moriyoshi Koizumi|Owner:  Moriyoshi
 |  Koizumi
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
  runserver  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by William Schwartz):

 Looks fine. The one change I'd make is that I'd change

 {{{#!python
 modspec.name.split(".")[-1] == "__main__"
 }}}

 to

 {{{#!python
 modspec.name == "__main__" or modspec.name.endswith(".__main__")
 }}}

 to avoid dumb corner cases like a module named `foo.my__main__` (which is
 how
 
[https://github.com/python/cpython/blob/fa03efda3dc6ad118788bebc61079cd481c0b24c/Lib/runpy.py#L143
 runpy.py] itself deals with 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/067.45c0349ad802f041970820204d14867c%40djangoproject.com.

Re: [Django] #32672: Primary Key, type double and type unsigned integer ain't detected correctly for Sqlite3 Database

[Django]

#32672: Primary Key, type double and type unsigned integer ain't detected 
correctly
for Sqlite3 Database
-+-
 Reporter:  juliangrube1988  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  SQLite3 PrimaryKey   | Triage Stage:
  Datatypes  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by juliangrube1988):

 * easy:  0 => 1


Old description:

> While creating models with "inspectdb" i discovered, that there are
> currently some issues with SQLite3 Databases.
> - PrimaryKeys ain't detected properly
> - Datatype double ain't detected properly
> - Datatype unsigned int ain't detected properly
>
> Reproduce these issues by creating a SQLite3 Database:
> CREATE TABLE "test" ( `pId` INTEGER NOT NULL, `doubleField` DOUBLE NOT
> NULL, `uInt` UNSIGNED INTEGER NOT NULL, PRIMARY KEY(`pId`) )

New description:

 While creating models with "inspectdb" i discovered, that there are
 currently some issues with SQLite3 Databases.
 - PrimaryKeys ain't detected properly
 - Datatype double ain't detected properly
 - Datatype unsigned int ain't detected properly

 Reproduce these issues by creating a SQLite3 Database:
 CREATE TABLE "test" ( `pId` INTEGER NOT NULL, `doubleField` DOUBLE NOT
 NULL, `uInt` UNSIGNED INTEGER NOT NULL, PRIMARY KEY(`pId`) )

 I added a pullrequest:
 https://github.com/django/django/pull/14293

--

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

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

Re: [Django] #16055: Filtering over generic relations with TextField/CharField object_id breaks in postgres

[Django]

#16055: Filtering over generic relations with TextField/CharField object_id 
breaks
in postgres
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.3
 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 Marc DEBUREAUX):

 Manage to create something based on Simon Charette's suggestion.

 Creating a custom `GenericRelation` with the following:
 - `get_joining_columns` returning an empty tuple
 - `get_extra_restriction` building the whole where clause with content
 type **AND** primary key join with Cast

 Here's the result:

 {{{#!python
 class CustomGenericRelation(GenericRelation):
 def get_joining_columns(self, reverse_join=False):
 joining_columns = super().get_joining_columns(reverse_join)
 self.joining_columns = joining_columns
 return tuple()

 def get_extra_restriction(self, where_class, alias, remote_alias):
 cond = super().get_extra_restriction(where_class, alias,
 remote_alias)
 from_field = self.model._meta.pk
 to_field =
 self.remote_field.model._meta.get_field(self.object_id_field_name)
 lookup = from_field.get_lookup('exact')(
 Cast(from_field.get_col(alias),
 output_field=models.TextField()),
 to_field.get_col(remote_alias))
 cond.add(lookup, 'AND')
 return cond
 }}}

 Giving the following:
 - a model `common.History` having a `GenericForeignKey` with `object_id`
 as text
 - a model `generic.Twitter` having a `CustomGenericRelation` and a numeric
 primary key
 - and the queryset:

 {{{#!python
 q =
 Twitter.objects.values('id').filter(id=1).annotate(count=Count('histories'))
 print(q.query)
 }}}

 It gives the following SQL query:

 {{{#!sql
 SELECT
 "generic_twitter"."id",
 COUNT("common_history"."id") AS "count"
 FROM "generic_twitter"
 LEFT OUTER JOIN "common_history" ON
 (((
 "common_history"."content_type_id" = 29 AND
 CAST("generic_twitter"."id" AS text) = "common_history"."object_id"
 )))
 WHERE "generic_twitter"."id" = 1
 GROUP BY "generic_twitter"."id"
 }}}

 Instead of this one (normal behaviour):

 {{{#!sql
 SELECT
 "generic_twitter"."id",
 COUNT("common_history"."id") AS "count"
 FROM "generic_twitter"
 LEFT OUTER JOIN "common_history" ON
 (
 "generic_twitter"."id" = "common_history"."object_id" AND
 ("common_history"."content_type_id" = 29)
 )
 WHERE "generic_twitter"."id" = 1
 GROUP BY "generic_twitter"."id"
 }}}

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

Re: [Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
--+
 Reporter:  Abhyudai  |Owner:  Abhyudai
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  documentation | 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/14295 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.a7fc219ef215b40d9e0f8efda20980ed%40djangoproject.com.

[Django] #32672: Primary Key, type double and type unsigned integer ain't detected correctly for Sqlite3 Database

[Django]

#32672: Primary Key, type double and type unsigned integer ain't detected 
correctly
for Sqlite3 Database
-+-
   Reporter: |  Owner:  nobody
  juliangrube1988|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:  SQLite3 PrimaryKey
   Severity:  Normal |  Datatypes
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 While creating models with "inspectdb" i discovered, that there are
 currently some issues with SQLite3 Databases.
 - PrimaryKeys ain't detected properly
 - Datatype double ain't detected properly
 - Datatype unsigned int ain't detected properly

 Reproduce these issues by creating a SQLite3 Database:
 CREATE TABLE "test" ( `pId` INTEGER NOT NULL, `doubleField` DOUBLE NOT
 NULL, `uInt` UNSIGNED INTEGER NOT NULL, PRIMARY KEY(`pId`) )

-- 
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/058.972ab0bd3323386df13af381b5b88fa8%40djangoproject.com.

Re: [Django] #32670: django.contrib.gis.GDALRaster support for vsi filesystems

[Django]

#32670: django.contrib.gis.GDALRaster support for vsi filesystems
+--
 Reporter:  Jordi Castells  |Owner:  Jordi Castells
 Type:  New feature |   Status:  assigned
Component:  GIS |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  raster  | 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):

 * owner:  nobody => Jordi Castells


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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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 Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * 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/067.4546227dfbb179d45dce6c632c41bea4%40djangoproject.com.

Re: [Django] #32671: CSS var() causes relative URLs to break in Safari

[Django]

#32671: CSS var() causes relative URLs to break in Safari
---+---
 Reporter:  Perry Roper|Owner:  Perry Roper
 Type:  Uncategorized  |   Status:  assigned
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+---
Changes (by Perry Roper):

 * owner:  nobody => Perry Roper
 * status:  new => assigned


Old description:

> There is a bug in Safari where using the var() property alongside a url()
> that contains a relative path, the relative path will break. The bug also
> existed in Chrome
> (https://bugs.chromium.org/p/chromium/issues/detail?id=618165), which has
> been fixed. However the Safari bug still exists as of Mac OS 11.2.3.
>
> **Expected Output**
>
> [[Image(https://i.imgur.com/r6rQuO6.png)]]
>
> **Actual Output**
>
> [[Image(https://i.imgur.com/eVqLZbP.png)]]
> [[Image(https://i.imgur.com/Tj3f0O4.png)]]
>
> As you can see from the console, the URLs end up being relative to the
> **current page URL**, not the CSS file URL in which they are loaded.
>
> This bug was introduced in
> https://github.com/django/django/commit/0a802233ec1421e5e59a486be69daef9b112fd0d

New description:

 There is a bug in Safari where using the var() property alongside a url()
 that contains a relative path, the relative path will break. The bug also
 existed in Chrome
 (https://bugs.chromium.org/p/chromium/issues/detail?id=618165), which has
 been fixed. However the Safari bug still exists as of Mac OS 11.2.3.

 **Expected Output**

 [[Image(https://i.imgur.com/r6rQuO6.png)]]

 **Actual Output**

 [[Image(https://i.imgur.com/eVqLZbP.png)]]
 [[Image(https://i.imgur.com/Tj3f0O4.png)]]

 As you can see from the console, the URLs end up being relative to the
 **current page URL**, not the CSS file URL in which they are loaded.

 This bug was introduced in
 
https://github.com/django/django/commit/0a802233ec1421e5e59a486be69daef9b112fd0d

 GitHub Pull Request: https://github.com/django/django/pull/14294

--

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

Re: [Django] #28628: Audit for and abolish all use of '\d' in regexes

[Django]

#28628: Audit for and abolish all use of '\d' in regexes
--+
 Reporter:  James Bennett |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+
Changes (by Mariusz Felisiak):

 * owner:  JunyiJ => (none)
 * status:  assigned => new
 * component:  Documentation => Core (Other)


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

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

[Django] #32671: CSS var() causes relative URLs to break in Safari

[Django]

#32671: CSS var() causes relative URLs to break in Safari
-+
   Reporter:  Perry Roper|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+
 There is a bug in Safari where using the var() property alongside a url()
 that contains a relative path, the relative path will break. The bug also
 existed in Chrome
 (https://bugs.chromium.org/p/chromium/issues/detail?id=618165), which has
 been fixed. However the Safari bug still exists as of Mac OS 11.2.3.

 **Expected Output**

 [[Image(https://i.imgur.com/r6rQuO6.png)]]

 **Actual Output**

 [[Image(https://i.imgur.com/eVqLZbP.png)]]
 [[Image(https://i.imgur.com/Tj3f0O4.png)]]

 As you can see from the console, the URLs end up being relative to the
 **current page URL**, not the CSS file URL in which they are loaded.

 This bug was introduced in
 
https://github.com/django/django/commit/0a802233ec1421e5e59a486be69daef9b112fd0d

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

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

Re: [Django] #32662: Refactor a generator out from part of SQLCompiler.get_order_by()

[Django]

#32662: Refactor a generator out from part of SQLCompiler.get_order_by()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #27694: Improve documentation of supported lookups on HStore & JSON fields

[Django]

#27694: Improve documentation of supported lookups on HStore & JSON fields
--+
 Reporter:  Stephen Burrows   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  dev
 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 Mariusz Felisiak):

 * easy:  0 => 1


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

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

Re: [Django] #27534: Add CSRF_COOKIE_HTTPONLY note to CSRF AJAX docs

[Django]

#27534: Add CSRF_COOKIE_HTTPONLY note to CSRF AJAX docs
-+-
 Reporter:  Andrew Charles   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 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):

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


Comment:

 Duplicate of #29879. Fixed in 76b3367035889d87ffef7a52cd44d70e30537f6f.

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

Re: [Django] #32662: Refactor a generator out from part of SQLCompiler.get_order_by()

[Django]

#32662: Refactor a generator out from part of SQLCompiler.get_order_by()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14292

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

Re: [Django] #32670: django.contrib.gis.GDALRaster support for vsi filesystems

[Django]

#32670: django.contrib.gis.GDALRaster support for vsi filesystems
+
 Reporter:  Jordi Castells  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  GIS |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  raster  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Mariusz Felisiak):

 [https://github.com/django/django/pull/14268 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.15389044fcd9aed4a9478bacd79d323c%40djangoproject.com.

Re: [Django] #32670: django.contrib.gis.GDALRaster support for vsi filesystems

[Django]

#32670: django.contrib.gis.GDALRaster support for vsi filesystems
+
 Reporter:  Jordi Castells  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  GIS |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  raster  | 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):

 * cc: Daniel Wiesmann (added)
 * keywords:   => raster
 * version:  3.2 => 4.0
 * stage:  Unreviewed => Accepted


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

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

[Django] #32670: django.contrib.gis.GDALRaster support for vsi filesystems

[Django]

#32670: django.contrib.gis.GDALRaster support for vsi filesystems
--+--
   Reporter:  Jordi Castells  |  Owner:  nobody
   Type:  New feature | Status:  assigned
  Component:  GIS |Version:  3.2
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 The GDAL library has out of the box support for different kinds of virtual
 filesystems (directly accessing data on ZIP, or networked filesystems).

 https://gdal.org/user/virtual_file_systems.html

 Those specific filesystems are enabled with a string prefix to the path
 sent to GDAL when instantiating a new raster.

 `django.contrib.gis.GDALRaster` does not support any of this special cases
 since it forces any string to either be an in memory gdal vsi path
 (strating with `/vsimem`) or an existing path in the filesystem.

 So for example, gdal will happily open `/vsizip//tmp/raster.zip` but
 `django.contrib.gis.GDALRaster` will refuse to do so even though the
 underlying library supports it.

 There are other specific cases that might benefit from it, for example a
 Cloud Optimized GeoTiff (COG) stored in an S3 file service. To read that
 raster into Django one has to download it first to the filesystem (or
 memory) and then pass it to `GDALRaster` beating the purpose of the COG in
 S3, while a `/vsis3` path can instantiate that COG file and just retrieve
 the data as needed thus reducing network usage.

 This could probably be a whole other discussion here on how to treat those
 kind of files in a less "gdaly" way (for example with specific
 `django.contrib.gis.GDALRaster` `driver` option, similar to the current
 `driver=MEM`). But a first straightforward step that would open those
 functionalities to djangogis is simply to let those `/vsi*` paths through
 instead of failing.

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

Re: [Django] #27106: Document which template filters can be used in Python code (and how)

[Django]

#27106: Document which template filters can be used in Python code (and how)
--+
 Reporter:  Baptiste Mispelon |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.10
 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):

 * owner:  Burhan Khalid => (none)
 * status:  assigned => new


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

Re: [Django] #15396: full path to modules in documentation inconsistently referenced

[Django]

#15396: full path to modules in documentation inconsistently referenced
---+
 Reporter:  slinkp@…   |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  dev
 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):

 * owner:  Mar Sánchez => (none)
 * status:  assigned => new


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

Re: [Django] #26827: "ModelState.fields cannot refer to a model class ... Use a string reference instead." when using custom model field derived from ManyToMany

[Django]

#26827: "ModelState.fields cannot refer to a model class ... Use a string 
reference
instead." when using custom model field derived from ManyToMany
--+
 Reporter:  Rich Rauenzahn|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  dev
 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):

 * owner:  Zaheer Soebhan => (none)
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * status:  assigned => new
 * needs_docs:  1 => 0


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

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

Re: [Django] #25996: Revise the Performance section in topics/http/urls

[Django]

#25996: Revise the Performance section in topics/http/urls
--+
 Reporter:  Tzu-ping Chung|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  dev
 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):

 * owner:  j-shu => (none)
 * status:  assigned => new


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

Re: [Django] #27149: Allow using a subquery in QuerySet.filter()

[Django]

#27149: Allow using a subquery in QuerySet.filter()
-+-
 Reporter:  MikiSoft |Owner:  Matthew
 |  Schinckel
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Queryset SubQuery| Triage Stage:  Ready for
  Exists |  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:"48e19bae49f271cccbb8a8f4549c9366b7cecac6" 48e19bae]:
 {{{
 #!CommitTicketReference repository=""
 revision="48e19bae49f271cccbb8a8f4549c9366b7cecac6"
 [3.2.x] Fixed #32650 -- Fixed handling subquery aliasing on queryset
 combination.

 This issue started manifesting itself when nesting a combined subquery
 relying on exclude() since 8593e162c9cb63a6c0b06daf045bc1c21eb4d7c1 but
 sql.Query.combine never properly handled subqueries outer refs in the
 first place, see QuerySetBitwiseOperationTests.test_subquery_aliases()
 (refs #27149).

 Thanks Raffaele Salmaso for the report.

 Backport of 6d0cbe42c3d382e5393d4af48185c546bb0ada1f from main
 }}}

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

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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 Mariusz Felisiak ):

 In [changeset:"48e19bae49f271cccbb8a8f4549c9366b7cecac6" 48e19bae]:
 {{{
 #!CommitTicketReference repository=""
 revision="48e19bae49f271cccbb8a8f4549c9366b7cecac6"
 [3.2.x] Fixed #32650 -- Fixed handling subquery aliasing on queryset
 combination.

 This issue started manifesting itself when nesting a combined subquery
 relying on exclude() since 8593e162c9cb63a6c0b06daf045bc1c21eb4d7c1 but
 sql.Query.combine never properly handled subqueries outer refs in the
 first place, see QuerySetBitwiseOperationTests.test_subquery_aliases()
 (refs #27149).

 Thanks Raffaele Salmaso for the report.

 Backport of 6d0cbe42c3d382e5393d4af48185c546bb0ada1f from main
 }}}

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

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (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
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"6d0cbe42c3d382e5393d4af48185c546bb0ada1f" 6d0cbe42]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d0cbe42c3d382e5393d4af48185c546bb0ada1f"
 Fixed #32650 -- Fixed handling subquery aliasing on queryset combination.

 This issue started manifesting itself when nesting a combined subquery
 relying on exclude() since 8593e162c9cb63a6c0b06daf045bc1c21eb4d7c1 but
 sql.Query.combine never properly handled subqueries outer refs in the
 first place, see QuerySetBitwiseOperationTests.test_subquery_aliases()
 (refs #27149).

 Thanks Raffaele Salmaso 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/066.b066922fa2f37ec7c4226d55d1fd8fd7%40djangoproject.com.

Re: [Django] #27149: Allow using a subquery in QuerySet.filter()

[Django]

#27149: Allow using a subquery in QuerySet.filter()
-+-
 Reporter:  MikiSoft |Owner:  Matthew
 |  Schinckel
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Queryset SubQuery| Triage Stage:  Ready for
  Exists |  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:"6d0cbe42c3d382e5393d4af48185c546bb0ada1f" 6d0cbe42]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d0cbe42c3d382e5393d4af48185c546bb0ada1f"
 Fixed #32650 -- Fixed handling subquery aliasing on queryset combination.

 This issue started manifesting itself when nesting a combined subquery
 relying on exclude() since 8593e162c9cb63a6c0b06daf045bc1c21eb4d7c1 but
 sql.Query.combine never properly handled subqueries outer refs in the
 first place, see QuerySetBitwiseOperationTests.test_subquery_aliases()
 (refs #27149).

 Thanks Raffaele Salmaso 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/066.d884363052a7310c69c4f279e3a60966%40djangoproject.com.

Re: [Django] #32669: Allow autoreloading of `python -m custom_module runserver` (was: Fix for #32314 causing problems with non-package dotted name specified to -m)

[Django]

#32669: Allow autoreloading of `python -m custom_module runserver`
-+-
 Reporter:  Moriyoshi Koizumi|Owner:  Moriyoshi
 |  Koizumi
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
  runserver  |
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 => assigned
 * cc: William Schwartz (added)
 * version:  3.2 => 4.0
 * owner:  nobody => Moriyoshi Koizumi
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Old description:

> The original fix [1] only attempted to deal with `-m foo.bar` where `bar`
> is a package and `__main__.py` exists under `foo/bar`.
>
> When a dotted name for a module (for example, `foo.bar.baz` where
> `baz.py` resides under `foo/bar`) is specified like `-m foo.bar.baz`, the
> resulting arguments end up being `-m foo.bar`, which is uncalled for.
>
> [1]
> https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3

New description:

 The original fix [1] only attempted to deal with `-m foo.bar` where `bar`
 is a package and `__main__.py` exists under `foo/bar`.

 When a dotted name for a module (for example, `foo.bar.baz` where `baz.py`
 resides under `foo/bar`) is specified like `-m foo.bar.baz`, the resulting
 arguments end up being `-m foo.bar`, which is uncalled for.

 [1]
 
https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3

 Fixed detection when started non-django modules with "python -m" in
 autoreloader.

--

Comment:

 It doesn't work in Django 3.1 so I would not call it a regression.

 Can you send PR via GitHub?

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

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  dev
 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):

 * stage:  Unreviewed => Accepted


Comment:

 Yes, thank you for the good explanation Chris, this makes sense.

 > By extracting out from setup() a setup_test_collection() function that
 just collects and returns the top-level, filtered test labels, I think
 things will become a lot easier to understand and work with -- not just
 for bisect_tests() and paired_tests(), but also for the main
 django_tests() case.

 I agree `setup()` is a ''little opaque'' so +1.
 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/067.bfe5c196a6b99f12feb0d6b5bafe9107%40djangoproject.com.

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  3.2
  checks)|
 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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1cc2eaf02d2aa64f7ca4ef52f3d9f13381540007" 1cc2eaf0]:
 {{{
 #!CommitTicketReference repository=""
 revision="1cc2eaf02d2aa64f7ca4ef52f3d9f13381540007"
 [3.2.x] Fixed #32665 -- Fixed caches system check crash when
 STATICFILES_DIRS is a list of 2-tuples.

 Thanks Jared Lockhart for the report.

 Regression in c36075ac1dddfa986340b1a5e15fe48833322372.
 Backport of 34d1905712d33e72c76b3a55a4fc24abbd11be6c from main
 }}}

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

Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  3.2
  checks)|
 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:  1|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"34d1905712d33e72c76b3a55a4fc24abbd11be6c" 34d1905]:
 {{{
 #!CommitTicketReference repository=""
 revision="34d1905712d33e72c76b3a55a4fc24abbd11be6c"
 Fixed #32665 -- Fixed caches system check crash when STATICFILES_DIRS is a
 list of 2-tuples.

 Thanks Jared Lockhart for the report.

 Regression in c36075ac1dddfa986340b1a5e15fe48833322372.
 }}}

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

Re: [Django] #32669: Fix for #32314 causing problems with non-package dotted name specified to -m

[Django]

#32669: Fix for #32314 causing problems with non-package dotted name specified 
to
-m
-+-
 Reporter:  Moriyoshi Koizumi|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload   | Triage Stage:
  runserver  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Moriyoshi Koizumi:

Old description:

> The original fix [1] only attempted to deal with "-m foo.bar" where bar
> is a package and __main__.py exists under foo/bar.
>
> When a dotted name for a module (for example, foo.bar.baz where baz.py
> resides under foo/bar) is specified like "-m foo.bar.baz", the resulting
> arguments end up being "-m foo.bar", which is uncalled for.
>
> [1]
> https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3

New description:

 The original fix [1] only attempted to deal with `-m foo.bar` where `bar`
 is a package and `__main__.py` exists under `foo/bar`.

 When a dotted name for a module (for example, `foo.bar.baz` where `baz.py`
 resides under `foo/bar`) is specified like `-m foo.bar.baz`, the resulting
 arguments end up being `-m foo.bar`, which is uncalled for.

 [1]
 
https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3

--

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

Re: [Django] #32669: Fix for #32314 causing problems with non-package dotted name specified to -m

[Django]

#32669: Fix for #32314 causing problems with non-package dotted name specified 
to
-m
-+-
 Reporter:  Moriyoshi Koizumi|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Utilities|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload   | Triage Stage:
  runserver  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Moriyoshi Koizumi):

 * Attachment "32669-autoreload-fix.patch.diff" added.

 Patch

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

[Django] #32669: Fix for #32314 causing problems with non-package dotted name specified to -m

[Django]

#32669: Fix for #32314 causing problems with non-package dotted name specified 
to
-m
-+-
   Reporter:  Moriyoshi  |  Owner:  nobody
  Koizumi|
   Type: | Status:  new
  Uncategorized  |
  Component:  Utilities  |Version:  3.2
   Severity:  Normal |   Keywords:  autoreload
   Triage Stage: |  runserver
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The original fix [1] only attempted to deal with "-m foo.bar" where bar is
 a package and __main__.py exists under foo/bar.

 When a dotted name for a module (for example, foo.bar.baz where baz.py
 resides under foo/bar) is specified like "-m foo.bar.baz", the resulting
 arguments end up being "-m foo.bar", which is uncalled for.

 [1]
 
https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3

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

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

Re: [Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
 Reporter:  varicocelehealing|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Admin, Changelist,   | Triage Stage:  Ready for
  Shift Click|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"54d5bfa9c5eb3e2936a0e382724869867059fad3" 54d5bfa9]:
 {{{
 #!CommitTicketReference repository=""
 revision="54d5bfa9c5eb3e2936a0e382724869867059fad3"
 [3.2.x] Fixed #32647 -- Restored multi-row select with shift-modifier in
 admin changelist.

 Regression in 30e59705fc3e3e9e8370b965af794ad6173bf92b.

 Backport of 5c73fbb6a93ee214678f02ba4027f18dff49337b from main
 }}}

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

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

Re: [Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
 Reporter:  varicocelehealing|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Admin, Changelist,   | Triage Stage:  Ready for
  Shift Click|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"5c73fbb6a93ee214678f02ba4027f18dff49337b" 5c73fbb]:
 {{{
 #!CommitTicketReference repository=""
 revision="5c73fbb6a93ee214678f02ba4027f18dff49337b"
 Fixed #32647 -- Restored multi-row select with shift-modifier in admin
 changelist.

 Regression in 30e59705fc3e3e9e8370b965af794ad6173bf92b.
 }}}

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

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

Re: [Django] #32662: Refactor a generator out from part of SQLCompiler.get_order_by()

[Django]

#32662: Refactor a generator out from part of SQLCompiler.get_order_by()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * 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/067.c7aea36fdd186b273782efbde243c449%40djangoproject.com.

Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  3.2
  checks)|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/071.8fa8a9917172f7183f28cbc0b0890b54%40djangoproject.com.

Re: [Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
 Reporter:  varicocelehealing|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  Admin, Changelist,   | Triage Stage:  Ready for
  Shift Click|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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