Re: [Django] #32943: Add support for covering indexes and exclusion constraints for SP-GiST in PostgreSQL 14+.

[Django]

#32943: Add support for covering indexes and exclusion constraints for SP-GiST 
in
PostgreSQL 14+.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql, spgist,  | Triage Stage:  Accepted
  index, exclusion, constraint,  |
  include, covering  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Someday/Maybe => Accepted


Comment:

 PostgreSQL 14 is [https://www.postgresql.org/docs/14/release-14.html
 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.f2727dd8a5ea39d896e48fff80f74ef8%40djangoproject.com.

Re: [Django] #32961: Add support for BIT_XOR aggregate in PostgreSQL 14+.

[Django]

#32961: Add support for BIT_XOR aggregate in PostgreSQL 14+.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql,  | Triage Stage:  Accepted
  aggregate, bit_xor |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Someday/Maybe => Accepted


Comment:

 PostgreSQL 14 is [https://www.postgresql.org/docs/14/release-14.html
 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.7859b7484797692ee8cdc258d542135e%40djangoproject.com.

Re: [Django] #33161: Do not ignore transaction durability errors within TestCase

[Django]

#33161: Do not ignore transaction durability errors within TestCase
-+-
 Reporter:  Krzysztof Jagiełło   |Owner:  Krzysztof
 |  Jagiełło
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: David Seddon, Adam Johnson, Ian Foote (added)


Comment:

 I don't think it's worth additional complexity and potential slowdown of
 `TestCase` for all users. I will wait for a second opinion before making a
 decision.

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

Re: [Django] #33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors from queries on PostgreSQL.

[Django]

#33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors 
from
queries on PostgreSQL.
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"81bb0ae2213019726a96becb5a1d906924dd5109" 81bb0ae2]:
 {{{
 #!CommitTicketReference repository=""
 revision="81bb0ae2213019726a96becb5a1d906924dd5109"
 [4.0.x] Fixed #33160 -- Avoided suppressing query errors in _nodb_cursor()
 on PostgreSQL.

 Backport of 98c8bf1ceeab5c68751c83555f82cff1a9120a67 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/065.6462ffdece338f8f34db22f23fca58f8%40djangoproject.com.

Re: [Django] #33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors from queries on PostgreSQL.

[Django]

#33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors 
from
queries on PostgreSQL.
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"98c8bf1ceeab5c68751c83555f82cff1a9120a67" 98c8bf1]:
 {{{
 #!CommitTicketReference repository=""
 revision="98c8bf1ceeab5c68751c83555f82cff1a9120a67"
 Fixed #33160 -- Avoided suppressing query errors in _nodb_cursor() on
 PostgreSQL.
 }}}

-- 
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.e0f981737f201cb2938b3e60e274d592%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:  (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:  1 |UI/UX:  0
--+

Comment (by Mariusz Felisiak):

 Replying to [comment:9 Sarah Abderemane]:
 > I'd be happy to help on this issue but HStore is new for me,
 {{{iexact}}} on HStoreField lookup, it's based on which SQL operator ?
 > Same as ''contains'' {{{@>}}} but it's with case-insensitive or another
 one ?

 `iexact` and other text-lookups should work on
 
[https://github.com/django/django/blob/492ed60f236d770eb9a6d56d85ff2550bb1ecfff/django/contrib/postgres/fields/hstore.py#L79-L88
 key transforms] on `HStoreField` because it returns `TextField`. Maybe
 it's enough to add a similar note to the one about `JSONField`, e.g.:
 {{{
 .. note::

 Key transforms can also be chained with: :lookup:`contains`,
 :lookup:`icontains`, :lookup:`endswith`, :lookup:`iendswith`,
 :lookup:`iexact`, :lookup:`regex`, :lookup:`iregex`,
 :lookup:`startswith`,
 and :lookup:`istartswith`.
 }}}
 This is untested so some tests will also be required.

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

Re: [Django] #22224: Non-nullable blank string-based model field validation doesn't prevent or clean `None`

[Django]

#4: Non-nullable blank string-based model field validation doesn't prevent 
or
clean `None`
-+-
 Reporter:  Simon Charette   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Jacob Walls):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14920 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/067.1e66fbb82680a6cb698d5bd53393c5e4%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:  (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:  1 |UI/UX:  0
--+

Comment (by Sarah Abderemane):

 I'd be happy to help on this issue but HStore is new for me, {{{iexact}}}
 on HStoreField lookup, it's based on which SQL operator ?
 Same as ''contains'' {{{@>}}} but it's with case-insensitive or another
 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/066.c5592fe6c544d06c78ba6a6946e1b877%40djangoproject.com.

Re: [Django] #33158: Severely degraded performance under ASGI compared to the typical WSGI deployment pattern

[Django]

#33158: Severely degraded performance under ASGI compared to the typical WSGI
deployment pattern
-+-
 Reporter:  Ryan Henning |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ryan Henning):

 > In any case the fix from #32889 is not compatible with the Python
 support matrix of 3.2.

 Django 3.2 depends on asgiref 3.3.2 which has `ThreadSensitiveContex` and
 support for Python 3.6 - 3.9. Therefore, there is no issue with the Python
 support matrix for Django 3.2. I make this final point only in case it
 affects your stance (it's good to have all the info). I respect your
 decision regardless.

 > The bottom line is we don't backport arbitrary new features into
 released versions of Django.

 I am not arguing for ''arbitrary'' features. Rather, this is a
 ''specific'' feature for which I've stated my reasons above. Thank you for
 considering my reasons. I'll rest my case.

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

Re: [Django] #32786: Make the subquery ordering clearing optimization more selectively

[Django]

#32786: Make the subquery ordering clearing optimization more selectively
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 Type:   |  Ljungberg
  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
-+-

Comment (by Hannes Ljungberg):

 A workaround until 4.0 is available is to add a high limit to the query,
 like `qs[:9]`. This will prevent the ordering from being cleared.

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

Re: [Django] #33161: Do not ignore transaction durability errors within TestCase

[Django]

#33161: Do not ignore transaction durability errors within TestCase
-+-
 Reporter:  Krzysztof Jagiełło   |Owner:  Krzysztof
 |  Jagiełło
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 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:  0
-+-
Changes (by Krzysztof Jagiełło):

 * version:  3.2 => dev


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

Re: [Django] #33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors from queries on PostgreSQL.

[Django]

#33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors 
from
queries on PostgreSQL.
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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 Daniel Hahler):

 * needs_tests:  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/065.571492b4f64b67e94d401d5c397d3f46%40djangoproject.com.

Re: [Django] #33161: Do not ignore transaction durability errors within TestCase

[Django]

#33161: Do not ignore transaction durability errors within TestCase
-+-
 Reporter:  Krzysztof Jagiełło   |Owner:  Krzysztof
 |  Jagiełło
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  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:  0
-+-
Changes (by Krzysztof Jagiełło):

 * owner:  nobody => Krzysztof Jagiełło
 * 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.eed587efbef025f496aedb4fcbe50137%40djangoproject.com.

Re: [Django] #33161: Do not ignore transaction durability errors within TestCase

[Django]

#33161: Do not ignore transaction durability errors within TestCase
+--
 Reporter:  Krzysztof Jagiełło  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Testing framework   |  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:  0
+--
Description changed by Krzysztof Jagiełło:

Old description:

> Currently there is a discrepancy in how durable atomic blocks are handled
> in `TransactionTestCase` vs `TestCase`. Using the former, nested durable
> atomic blocks will, as expected, result in a `RuntimeError`. Using the
> latter however, the error will go unnoticed as the durability check is
> turned off.
>
> I have faced some issues with this behaviour in a codebase where we
> heavily utilize `TestCase` and where we recently started to introduce
> durable atomic blocks – the durability errors do not surface until the
> code hits staging/production. The solution could be to switch over to
> `TransactionTestCase` for the test classes that hit code paths with
> durable atomic blocks, but having to identify which tests could be
> affected by this issue is a bit inconvenient. And then there is the
> performance penalty of using `TransactionTestCase`.
>
> So, to the issue at hand. The durability check is disabled for `TestCase`
> because otherwise durable atomic blocks would fail immediately as
> `TestCase` wraps its tests in transactions. We could however add a marker
> to the transactions created by `TestCase`, keep a stack of active
> transactions and make the durability check take the stack of transactions
> with their respective markers into account. This way we could easily
> detect when a durable atomic block is directly within a transaction
> created by `TestCase` and skip the durability check only for this
> specific scenario.
>
> To better illustrate what I am proposing here, I have prepared a PoC
> patch. Let me know what you think!
>
> Patch: Coming soon

New description:

 Currently there is a discrepancy in how durable atomic blocks are handled
 in `TransactionTestCase` vs `TestCase`. Using the former, nested durable
 atomic blocks will, as expected, result in a `RuntimeError`. Using the
 latter however, the error will go unnoticed as the durability check is
 turned off.

 I have faced some issues with this behaviour in a codebase where we
 heavily utilize `TestCase` and where we recently started to introduce
 durable atomic blocks – the durability errors do not surface until the
 code hits staging/production. The solution could be to switch over to
 `TransactionTestCase` for the test classes that hit code paths with
 durable atomic blocks, but having to identify which tests could be
 affected by this issue is a bit inconvenient. And then there is the
 performance penalty of using `TransactionTestCase`.

 So, to the issue at hand. The durability check is disabled for `TestCase`
 because otherwise durable atomic blocks would fail immediately as
 `TestCase` wraps its tests in transactions. We could however add a marker
 to the transactions created by `TestCase`, keep a stack of active
 transactions and make the durability check take the stack of transactions
 with their respective markers into account. This way we could easily
 detect when a durable atomic block is directly within a transaction
 created by `TestCase` and skip the durability check only for this specific
 scenario.

 To better illustrate what I am proposing here, I have prepared a PoC
 patch. Let me know what you think!

 Patch: https://github.com/django/django/pull/14919

--

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

[Django] #33161: Do not ignore transaction durability errors within TestCase

[Django]

#33161: Do not ignore transaction durability errors within TestCase
--+
   Reporter:  Krzysztof Jagiełło  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  Testing framework   |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   |
--+
 Currently there is a discrepancy in how durable atomic blocks are handled
 in `TransactionTestCase` vs `TestCase`. Using the former, nested durable
 atomic blocks will, as expected, result in a `RuntimeError`. Using the
 latter however, the error will go unnoticed as the durability check is
 turned off.

 I have faced some issues with this behaviour in a codebase where we
 heavily utilize `TestCase` and where we recently started to introduce
 durable atomic blocks – the durability errors do not surface until the
 code hits staging/production. The solution could be to switch over to
 `TransactionTestCase` for the test classes that hit code paths with
 durable atomic blocks, but having to identify which tests could be
 affected by this issue is a bit inconvenient. And then there is the
 performance penalty of using `TransactionTestCase`.

 So, to the issue at hand. The durability check is disabled for `TestCase`
 because otherwise durable atomic blocks would fail immediately as
 `TestCase` wraps its tests in transactions. We could however add a marker
 to the transactions created by `TestCase`, keep a stack of active
 transactions and make the durability check take the stack of transactions
 with their respective markers into account. This way we could easily
 detect when a durable atomic block is directly within a transaction
 created by `TestCase` and skip the durability check only for this specific
 scenario.

 To better illustrate what I am proposing here, I have prepared a PoC
 patch. Let me know what you think!

 Patch: Coming soon

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

Re: [Django] #32518: Document that QuerySet.contains() should not be overused.

[Django]

#32518: Document that QuerySet.contains() should not be overused.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Pradhvan
 Type:   |  Bisht
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  4.0
 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 Pradhvan Bisht ):

 * owner:  AdamDonna => Pradhvan Bisht


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

Re: [Django] #32518: Document that QuerySet.contains() should not be overused.

[Django]

#32518: Document that QuerySet.contains() should not be overused.
-+-
 Reporter:  Mariusz Felisiak |Owner:  AdamDonna
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.0
 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
-+-

Comment (by Pradhvan Bisht ):

 SInce the PR [https://github.com/django/django/pull/14161] is closed, I
 think Adam is not working on it.

 I would be happy to take this up since `tim-mccurrach` has left quite a
 detailed note on the PR and it would be easy for me to pick up the
 recommendation and add it in a separate 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.b62b804cabb6e48e0956c6c58d0eea4d%40djangoproject.com.

Re: [Django] #33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors from queries on PostgreSQL. (was: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django was

[Django]

#33160: DatabaseWrapper._nodb_cursor() raises wrong warnings in case of errors 
from
queries on PostgreSQL.
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Daniel Hahler
 * status:  new => assigned
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks 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/065.7a500fb799dc1e0601cfeb5ff609010d%40djangoproject.com.

Re: [Django] #32786: Make the subquery ordering clearing optimization more selectively

[Django]

#32786: Make the subquery ordering clearing optimization more selectively
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 Type:   |  Ljungberg
  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
-+-

Comment (by Mariusz Felisiak):

 > So to me this looks like a regression in 3.2.

 This behavior was changed in Django 3.0 so per our backporting policy this
 means it doesn't qualify for a backport to 3.2.x, even if we consider it a
 regression.

 See  [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions supported versions policy] for more details.

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

Re: [Django] #33029: Can't open multiple Django Admin Popups for the same related field.

[Django]

#33029: Can't open multiple Django Admin Popups for the same related field.
-+-
 Reporter:  Yash Jhunjhunwala|Owner:  Yash
 |  Jhunjhunwala
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  3.2
 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:  1
-+-
Changes (by Carlton Gibson ):

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


Comment:

 In [changeset:"492ed60f236d770eb9a6d56d85ff2550bb1ecfff" 492ed60]:
 {{{
 #!CommitTicketReference repository=""
 revision="492ed60f236d770eb9a6d56d85ff2550bb1ecfff"
 Fixed #33029 -- Allowed multiple popups for self-related fields in admin.
 }}}

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

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

Re: [Django] #32786: Make the subquery ordering clearing optimization more selectively

[Django]

#32786: Make the subquery ordering clearing optimization more selectively
-+-
 Reporter:  Hannes Ljungberg |Owner:  Hannes
 Type:   |  Ljungberg
  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
-+-

Comment (by Andi Albrecht):

 Do I may bring up this issue again? I've stumbled upon a similar issue as
 reported in #32658 or #32786. Both were closed as invalid. However, this
 change added a test case to Django's main branch (which will be 4.0 if I'm
 not wrong) that tests a scenario that’s pretty similar to the code in the
 application I’m migrating from 2.2 LTS to 3.2 LTS. The test case looks
 totally legit to me and not like an abuse of the ORM:

 {{{
 def test_ordering_isnt_cleared_for_array_subquery(self):
 inner_qs = AggregateTestModel.objects.order_by('-integer_field')
 qs = AggregateTestModel.objects.annotate(
 integers=Func(
 Subquery(inner_qs.values('integer_field')),
 function='ARRAY',
 output_field=ArrayField(base_field=IntegerField()),
 ),
 )
 self.assertSequenceEqual(
 qs.first().integers,
 inner_qs.values_list('integer_field', flat=True),
 )
 }}}

 When adding this test case to the Django 2.2 code base, the test passes.
 When adding it to 3.2 it fails due to the removal of ordering. Of course
 in main it passes too. So to me this looks like a regression in 3.2.

 I did a quick test and cherry-picked both changes form this ticket in my
 local 3.2 branch without much issues. Six tests in postgres_tests were
 failing because of different warnings, but the same six tests fail on a
 clean 3.2 branch on my machine too.

 Wouldn’t it be an option to backport these changes to 3.2 to have a
 consistent behavior in 2.2, 3.2 and the upcoming 4.x release?

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

Re: [Django] #33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django was unable to create a connection to the 'postgres' database" warning in case of errors from queries

[Django]

#33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django 
was
unable to create a connection to the 'postgres' database" warning in case
of errors from queries
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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:  0
-+-
Description changed by Daniel Hahler:

Old description:

> {{_nodb_cursor}} might cause a confusing/wrong warning, e.g. via
> {{teardown_database}}:
>
> {{{
>   [35] …/Vcs/django/django/test/utils.py(313)teardown_databases()
>connection.creation.destroy_test_db(old_name, verbosity, keepdb)
>   [36]
> …/Vcs/django/django/db/backends/base/creation.py(282)destroy_test_db()
>self._destroy_test_db(test_database_name, verbosity)
>   [37]
> …/Vcs/django/django/db/backends/base/creation.py(298)_destroy_test_db()
>cursor.execute("DROP DATABASE %s"
>   [38] /usr/lib/python3.9/contextlib.py(137)__exit__()
>self.gen.throw(typ, value, traceback)
> > [39]
> …/Vcs/django/django/db/backends/postgresql/base.py(306)_nodb_cursor()
>warnings.warn(
> (Pdb++) l
> 301 with super()._nodb_cursor() as cursor:
> 302 yield cursor
> 303 except (Database.DatabaseError, WrappedDatabaseError) as
> exc:
> 304 e = exc
> 305 __import__('pdb').set_trace()
> 306  -> warnings.warn(
> 307 "Normally Django will use a connection to the
> 'postgres' database "
> 308 "to avoid running initialization queries against
> the production "
> 309 "database when it's not needed (for example, when
> running tests). "
> 310 "Django was unable to create a connection to the
> 'postgres' database "
> 311 "and will use the first PostgreSQL database
> instead.",
> (Pdb++) e
> OperationalError('database "test_foo" is being accessed by other
> users\nDETAIL:  There is 1 other session using the database.\n')
> }}}
>
> As you can see there is another issue this will (partly) swallow/hide
> then, apart from the message being just wrong: it is not the connection
> that failed, but a query in there:
>
> {{{
> [37] >
> …/django/django/db/backends/base/creation.py(298)_destroy_test_db(), 4
> frames hidden
>
> 289 def _destroy_test_db(self, test_database_name, verbosity):
> 290 """
> 291 Internal implementation - remove the test db tables.
> 292 """
> 293 # Remove the test database to clean up after
> 294 # ourselves. Connect to the previous database (not the
> test database)
> 295 # to do so, because it's not allowed to delete a database
> while being
> 296 # connected to it.
> 297 with self._nodb_cursor() as cursor:
> 298  -> cursor.execute("DROP DATABASE %s"
> 299%
> self.connection.ops.quote_name(test_database_name))
> }}}
>
> Only {{connect()} should get wrapped/handled in {{_nodb_cursor}} probably
> (in terms of adding the warning), which could be achieved by handling
> specific exceptions only, or re-raising it in case a {{cursor}} was used
> (i.e. it could connect).

New description:

 {{_nodb_cursor}} might cause a confusing/wrong warning, e.g. via
 {{teardown_database}}:

 {{{
   [35] …/Vcs/django/django/test/utils.py(313)teardown_databases()
connection.creation.destroy_test_db(old_name, verbosity, keepdb)
   [36]
 …/Vcs/django/django/db/backends/base/creation.py(282)destroy_test_db()
self._destroy_test_db(test_database_name, verbosity)
   [37]
 …/Vcs/django/django/db/backends/base/creation.py(298)_destroy_test_db()
cursor.execute("DROP DATABASE %s"
   [38] /usr/lib/python3.9/contextlib.py(137)__exit__()
self.gen.throw(typ, value, traceback)
 > [39]
 …/Vcs/django/django/db/backends/postgresql/base.py(306)_nodb_cursor()
warnings.warn(
 (Pdb++) l
 301 with super()._nodb_cursor() as cursor:
 302 yield cursor
 303 except (Database.DatabaseError, WrappedDatabaseError) as
 exc:
 304 e = exc
 305 __import__('pdb').set_trace()
 306  -> warnings.warn(
 307 "Normally Django will use a connection to 

Re: [Django] #33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django was unable to create a connection to the 'postgres' database" warning in case of errors from queries

[Django]

#33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django 
was
unable to create a connection to the 'postgres' database" warning in case
of errors from queries
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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:  0
-+-
Changes (by Daniel Hahler):

 * has_patch:  0 => 1


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

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

[Django] #33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django was unable to create a connection to the 'postgres' database" warning in case of errors from queries

[Django]

#33160: postgresql DatabaseWrapper._nodb_cursor causes confusing/wrong "Django 
was
unable to create a connection to the 'postgres' database" warning in case
of errors from queries
-+-
   Reporter:  Daniel |  Owner:  nobody
  Hahler |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  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  |
-+-
 {{_nodb_cursor}} might cause a confusing/wrong warning, e.g. via
 {{teardown_database}}:

 {{{
   [35] …/Vcs/django/django/test/utils.py(313)teardown_databases()
connection.creation.destroy_test_db(old_name, verbosity, keepdb)
   [36]
 …/Vcs/django/django/db/backends/base/creation.py(282)destroy_test_db()
self._destroy_test_db(test_database_name, verbosity)
   [37]
 …/Vcs/django/django/db/backends/base/creation.py(298)_destroy_test_db()
cursor.execute("DROP DATABASE %s"
   [38] /usr/lib/python3.9/contextlib.py(137)__exit__()
self.gen.throw(typ, value, traceback)
 > [39]
 …/Vcs/django/django/db/backends/postgresql/base.py(306)_nodb_cursor()
warnings.warn(
 (Pdb++) l
 301 with super()._nodb_cursor() as cursor:
 302 yield cursor
 303 except (Database.DatabaseError, WrappedDatabaseError) as
 exc:
 304 e = exc
 305 __import__('pdb').set_trace()
 306  -> warnings.warn(
 307 "Normally Django will use a connection to the
 'postgres' database "
 308 "to avoid running initialization queries against
 the production "
 309 "database when it's not needed (for example, when
 running tests). "
 310 "Django was unable to create a connection to the
 'postgres' database "
 311 "and will use the first PostgreSQL database
 instead.",
 (Pdb++) e
 OperationalError('database "test_foo" is being accessed by other
 users\nDETAIL:  There is 1 other session using the database.\n')
 }}}

 As you can see there is another issue this will (partly) swallow/hide
 then, apart from the message being just wrong: it is not the connection
 that failed, but a query in there:

 {{{
 [37] >
 …/django/django/db/backends/base/creation.py(298)_destroy_test_db(), 4
 frames hidden

 289 def _destroy_test_db(self, test_database_name, verbosity):
 290 """
 291 Internal implementation - remove the test db tables.
 292 """
 293 # Remove the test database to clean up after
 294 # ourselves. Connect to the previous database (not the
 test database)
 295 # to do so, because it's not allowed to delete a database
 while being
 296 # connected to it.
 297 with self._nodb_cursor() as cursor:
 298  -> cursor.execute("DROP DATABASE %s"
 299%
 self.connection.ops.quote_name(test_database_name))
 }}}

 Only {{connect()} should get wrapped/handled in {{_nodb_cursor}} probably
 (in terms of adding the warning), which could be achieved by handling
 specific exceptions only, or re-raising it in case a {{cursor}} was used
 (i.e. it could connect).

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

Re: [Django] #33029: Can't open multiple Django Admin Popups for the same related field.

[Django]

#33029: Can't open multiple Django Admin Popups for the same related field.
-+-
 Reporter:  Yash Jhunjhunwala|Owner:  Yash
 |  Jhunjhunwala
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 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:  1
-+-
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/061.d8f0e5fdff479913d2310145cc1e48a3%40djangoproject.com.

Re: [Django] #33156: Admin Sidebar search value stays forever

[Django]

#33156: Admin Sidebar search value stays forever
-+-
 Reporter:  Collin Anderson  |Owner:  Maxim
 |  Milovanov
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * status:  closed => new
 * has_patch:  0 => 1
 * resolution:  fixed =>


Comment:

 Hi Maxim. Thanks for the patch.

 I'll reopen the ticket as it's not "fixed" until that's merged.

-- 
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/072.5406c4227044fc3278b54d904310d5ff%40djangoproject.com.

Re: [Django] #33156: Admin Sidebar search value stays forever

[Django]

#33156: Admin Sidebar search value stays forever
-+-
 Reporter:  Collin Anderson  |Owner:  Maxim
 |  Milovanov
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 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 Maxim Milovanov):

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


Comment:

 hey guys,

 I've changed the storage from `localStorage` to `sessionStorage`.
 https://github.com/django/django/pull/14917

 Thanks for the suggestion.

-- 
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/072.f5454dd009762b80c9e3b21f1c04d181%40djangoproject.com.

Re: [Django] #33156: Admin Sidebar search value stays forever

[Django]

#33156: Admin Sidebar search value stays forever
-+-
 Reporter:  Collin Anderson  |Owner:  Maxim
 |  Milovanov
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 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 Maxim Milovanov):

 * owner:  nobody => Maxim Milovanov
 * 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/072.dd156291d25840a117038e8962a4caa6%40djangoproject.com.

Re: [Django] #33155: ModelChoiceIteratorValue is not hashable.

[Django]

#33155: ModelChoiceIteratorValue is not hashable.
-+-
 Reporter:  Aljaž Košir  |Owner:  Aljaž
 |  Košir
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  ModelChoiceIteratorValue   |  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:"0a49276065575867fbbf279f138b399c535e3b6d" 0a492760]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a49276065575867fbbf279f138b399c535e3b6d"
 [4.0.x] Fixed #33155 -- Made ModelChoiceIteratorValue instances hashable.

 Backport of 7b8b3d45cafd7bec7ff3ee0e4371e142c36d 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.25d6181536320b4be3a17677844e6e67%40djangoproject.com.

Re: [Django] #33155: ModelChoiceIteratorValue is not hashable.

[Django]

#33155: ModelChoiceIteratorValue is not hashable.
-+-
 Reporter:  Aljaž Košir  |Owner:  Aljaž
 |  Košir
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  ModelChoiceIteratorValue   |  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:"7b8b3d45cafd7bec7ff3ee0e4371e142c36d" 7b8beee]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b8b3d45cafd7bec7ff3ee0e4371e142c36d"
 Fixed #33155 -- Made ModelChoiceIteratorValue instances hashable.
 }}}

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

Re: [Django] #33155: ModelChoiceIteratorValue is not hashable.

[Django]

#33155: ModelChoiceIteratorValue is not hashable.
-+-
 Reporter:  Aljaž Košir  |Owner:  Aljaž
 |  Košir
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
  ModelChoiceIteratorValue   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * type:  Cleanup/optimization => Bug
 * 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/068.708897207e8bddda4a7139757883a7b8%40djangoproject.com.

Re: [Django] #32970: Investigate feasibility of improving WhereNode clone performance

[Django]

#32970: Investigate feasibility of improving WhereNode clone performance
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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):

 * resolution:  fixed => wontfix


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

Re: [Django] #32970: Investigate feasibility of improving WhereNode clone performance

[Django]

#32970: Investigate feasibility of improving WhereNode clone performance
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"93a42d43a6995993b9bbcb743ab3c2a2b8414ebd" 93a42d43]:
 {{{
 #!CommitTicketReference repository=""
 revision="93a42d43a6995993b9bbcb743ab3c2a2b8414ebd"
 [4.0.x] Fixed #33159 -- Reverted "Fixed #32970 -- Changed
 WhereNode.clone() to create a shallow copy of children."

 This reverts commit e441847ecae99dd1ccd0d9ce76dbcff51afa863c.

 A shallow copy is not enough because querysets can be reused and
 evaluated in nested nodes, which shouldn't mutate JOIN aliases.

 Thanks Michal Čihař for the report.
 Backport of 903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4 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/067.e0b1b18f4f41df844faa12f61e844341%40djangoproject.com.

Re: [Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
 Reporter:  Michal Čihař |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"93a42d43a6995993b9bbcb743ab3c2a2b8414ebd" 93a42d43]:
 {{{
 #!CommitTicketReference repository=""
 revision="93a42d43a6995993b9bbcb743ab3c2a2b8414ebd"
 [4.0.x] Fixed #33159 -- Reverted "Fixed #32970 -- Changed
 WhereNode.clone() to create a shallow copy of children."

 This reverts commit e441847ecae99dd1ccd0d9ce76dbcff51afa863c.

 A shallow copy is not enough because querysets can be reused and
 evaluated in nested nodes, which shouldn't mutate JOIN aliases.

 Thanks Michal Čihař for the report.
 Backport of 903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4 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/063.f1077a0bfd6139504daa7269b23ca518%40djangoproject.com.

Re: [Django] #32970: Investigate feasibility of improving WhereNode clone performance

[Django]

#32970: Investigate feasibility of improving WhereNode clone performance
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  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
-+-

Comment (by GitHub ):

 In [changeset:"903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4" 903aaa3]:
 {{{
 #!CommitTicketReference repository=""
 revision="903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4"
 Fixed #33159 -- Reverted "Fixed #32970 -- Changed WhereNode.clone() to
 create a shallow copy of children."

 This reverts commit e441847ecae99dd1ccd0d9ce76dbcff51afa863c.

 A shallow copy is not enough because querysets can be reused and
 evaluated in nested nodes, which shouldn't mutate JOIN aliases.

 Thanks Michal Čihař 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.8969874084aa386576d5edb9da24309e%40djangoproject.com.

Re: [Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
 Reporter:  Michal Čihař |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4" 903aaa3]:
 {{{
 #!CommitTicketReference repository=""
 revision="903aaa35e5ceaa33bfc9b19b7f6da65ce5a91dd4"
 Fixed #33159 -- Reverted "Fixed #32970 -- Changed WhereNode.clone() to
 create a shallow copy of children."

 This reverts commit e441847ecae99dd1ccd0d9ce76dbcff51afa863c.

 A shallow copy is not enough because querysets can be reused and
 evaluated in nested nodes, which shouldn't mutate JOIN aliases.

 Thanks Michal Čihař 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/063.73eec5fc2a535307b356ead379352415%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:  dev
 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 Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 A few minor tweaks remaining.

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

Re: [Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
 Reporter:  Michal Čihař |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   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/14916 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/063.8bdbe1de5193aa771674575b9984e991%40djangoproject.com.

Re: [Django] #33029: Can't open multiple Django Admin Popups for the same related field.

[Django]

#33029: Can't open multiple Django Admin Popups for the same related field.
-+-
 Reporter:  Yash Jhunjhunwala|Owner:  Yash
 |  Jhunjhunwala
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 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:  1
-+-
Changes (by Yash Jhunjhunwala):

 * needs_better_patch:  1 => 0


Comment:

 Updated the patch as per the changes suggested by Carlton

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

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

Re: [Django] #33155: ModelChoiceIteratorValue is not hashable.

[Django]

#33155: ModelChoiceIteratorValue is not hashable.
-+-
 Reporter:  Aljaž Košir  |Owner:  Aljaž
 Type:   |  Košir
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ModelChoiceIteratorValue   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Aljaž Košir):

 * needs_tests:  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/068.79df03ece52c951d2732b18ee33a45c2%40djangoproject.com.

Re: [Django] #33155: ModelChoiceIteratorValue is not hashable.

[Django]

#33155: ModelChoiceIteratorValue is not hashable.
-+-
 Reporter:  Aljaž Košir  |Owner:  Aljaž
 Type:   |  Košir
  Cleanup/optimization   |   Status:  assigned
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ModelChoiceIteratorValue   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Aljaž Košir):

 * needs_better_patch:  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/068.b02907f96cbbdceaf2434882038b41ac%40djangoproject.com.

Re: [Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
 Reporter:  Michal Čihař |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * 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/063.507eeb2703a730b16b435e4ea45d8aae%40djangoproject.com.

Re: [Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
 Reporter:  Michal Čihař |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Keryn Knight (added)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report!

 Regression in e441847ecae99dd1ccd0d9ce76dbcff51afa863c, TBH I was pretty
 sure that this would introduce some regression, now we will have a proper
 regression 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.40f2aefaa8f4caaef8999d8332cbefff%40djangoproject.com.

[Django] #33159: Missing table alias in generated query after used in subquery

[Django]

#33159: Missing table alias in generated query after used in subquery
-+-
   Reporter:  Michal |  Owner:  nobody
  Čihař  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When running our tests against 4.0a1, it fails with:

 {{{
  Traceback (most recent call last):
   File "/opt/hostedtoolcache/Python/3.9.7/x64/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "U0"
 LINE 1: ...UNT(*) AS "__count" FROM "trans_component" WHERE ("U0"."repo...
 }}}

 It seems that the table alias is missing from the query. Full log can be
 seen at
 https://github.com/WeblateOrg/weblate/pull/6608/checks?check_run_id=3751233865


 Reproducing outside the test case:

 {{{
 >>> from weblate.trans.models import Component
 >>> from django.db.models import Q
 >>> c = Component.objects.filter(Q(repo__in=('x', 'y')) |
 Q(repo__endswith=''))
 >>> c.count()
 0
 >>> Component.objects.filter(linked_component__in=c).count()
 0
 >>> c.count()
 Traceback (most recent call last):
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "U0"
 LINE 1: ...UNT(*) AS "__count" FROM "trans_component" WHERE ("U0"."repo...
  ^


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

 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/models/query.py", line 416, in count
 return self.query.get_count(using=self.db)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 515, in get_count
 number = obj.get_aggregation(using, ['__count'])['__count']
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/models/sql/query.py", line 500, in get_aggregation
 result = compiler.execute_sql(SINGLE)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/models/sql/compiler.py", line 1198, in execute_sql
 cursor.execute(sql, params)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 98, in execute
 return super().execute(sql, params)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 66, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 75, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/utils.py", line 90, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/nijel/weblate/weblate/.venv/lib/python3.9/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: missing FROM-clause entry for table "U0"
 LINE 1: ...UNT(*) AS "__count" FROM "trans_component" WHERE ("U0"."repo...
  ^

 }}}

 Note:

 * The queryset has to consist of multiple Q
 * Calling count on the queryset works until it is used in a subquery

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

Re: [Django] #33029: Can't open multiple Django Admin Popups for the same related field.

[Django]

#33029: Can't open multiple Django Admin Popups for the same related field.
-+-
 Reporter:  Yash Jhunjhunwala|Owner:  Yash
 |  Jhunjhunwala
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 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:  1
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Just some small tweaks to the behaviour and tests still needed. But patch
 look sound generally.

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

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

Re: [Django] #33158: Severely degraded performance under ASGI compared to the typical WSGI deployment pattern

[Django]

#33158: Severely degraded performance under ASGI compared to the typical WSGI
deployment pattern
-+-
 Reporter:  Ryan Henning |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Ryan — sorry, this is just the same request as #33157.

 The use of `ThreadSensitiveContex` from #32889 doesn't qualify for a
 backport. The bottom line is we don't backport arbitrary new features into
 released versions of Django. That does mean that folks need to upgrade to
 get the benefits of new features (which is the negative) but it's also a
 large part of why Django is so stable and reliable (the pro). On balance
 it's not worth the regression risk, and so the backport policy is as it
 is. I hope that makes sense.

 In any case the fix from #32889 is not compatible with the Python support
 matrix of 3.2.

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

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