Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Carlton Gibson (added)


Comment:

 It was added in b00046d2c25771bed2242680b08b524a44aa9798.

-- 
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/0107018bd713cf27-fbaf0bae-675d-4ba1-9f77-b5e09862fd21-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Janzen):

 > Django 5.0+ required asgiref 3.7+. Do you think it's time to remove this
 warning?

 Yeah that's probably a good idea, I completely missed that you added this
 warning

-- 
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/0107018bd6856783-fac3aa26-5ff1-4c72-a11d-84e30973f227-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:7 Jon Janzen]:
 > > Also, be aware that sync_to_async() and async_to_sync() are not
 compatible with @sensitive_variables (as ​documented).
 >
 > We might want to update those docs, as recent versions (>= 3.7.0) will
 hide variables from the internals of asgiref:
 https://github.com/django/asgiref/pull/383
 >
 > Changelog note for asgiref:
 https://github.com/django/asgiref/blob/main/CHANGELOG.txt#L25

 Django 5.0+ required asgiref 3.7+. Do you think it's time to remove this
 warning?

-- 
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/0107018bd682bf2e-158a7a64-c784-4093-af65-835a91108808-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Janzen):

 > Also, be aware that sync_to_async() and async_to_sync() are not
 compatible with @sensitive_variables (as ​documented).

 We might want to update those docs, as recent versions (>= 3.7.0) will
 hide variables from the internals of asgiref:
 https://github.com/django/asgiref/pull/383

 Changelog note for asgiref:
 https://github.com/django/asgiref/blob/main/CHANGELOG.txt#L25

-- 
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/0107018bd6475bb1-cd374684-990a-4bc1-83c2-3928fd6a7510-00%40eu-central-1.amazonses.com.

Re: [Django] #34970: Unclear wording in password validator docs

[Django]

#34970: Unclear wording in password validator docs
-+-
 Reporter:  Markus Amalthea  |Owner:  Markus
  Magnuson   |  Amalthea Magnuson
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.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:  0
-+-

Comment (by Natalia Bidart <124304+nessita@…>):

 In [changeset:"8c88ae8251da7f4fa01c1422f76fbb73aa41fffa" 8c88ae8]:
 {{{
 #!CommitTicketReference repository=""
 revision="8c88ae8251da7f4fa01c1422f76fbb73aa41fffa"
 [5.0.x] Fixed #34970 -- Clarified Password Validation docs regarding the
 password_changed callback.

 Backport of 61c305f298da1b4079a80721c861d0663dc8717e 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/0107018bd59d856a-506d2ede-bac6-4d15-a7e1-f85ca5291579-00%40eu-central-1.amazonses.com.

Re: [Django] #34970: Unclear wording in password validator docs

[Django]

#34970: Unclear wording in password validator docs
-+-
 Reporter:  Markus Amalthea  |Owner:  Markus
  Magnuson   |  Amalthea Magnuson
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.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:  0
-+-

Comment (by Natalia Bidart <124304+nessita@…>):

 In [changeset:"47f9b8dca16b1fdc054b338d81eb080eabad0edf" 47f9b8d]:
 {{{
 #!CommitTicketReference repository=""
 revision="47f9b8dca16b1fdc054b338d81eb080eabad0edf"
 [4.2.x] Fixed #34970 -- Clarified Password Validation docs regarding the
 password_changed callback.

 Backport of 61c305f298da1b4079a80721c861d0663dc8717e 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/0107018bd59d0271-fad1865f-bee9-4fb7-8794-eeba05daeec0-00%40eu-central-1.amazonses.com.

Re: [Django] #34970: Unclear wording in password validator docs

[Django]

#34970: Unclear wording in password validator docs
-+-
 Reporter:  Markus Amalthea  |Owner:  Markus
  Magnuson   |  Amalthea Magnuson
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.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:  0
-+-
Changes (by Natalia Bidart <124304+nessita@…>):

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


Comment:

 In [changeset:"61c305f298da1b4079a80721c861d0663dc8717e" 61c305f]:
 {{{
 #!CommitTicketReference repository=""
 revision="61c305f298da1b4079a80721c861d0663dc8717e"
 Fixed #34970 -- Clarified Password Validation docs regarding the
 password_changed callback.
 }}}

-- 
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/0107018bd59c143a-2c2140ea-8a66-4633-87f4-b8fa72b7367e-00%40eu-central-1.amazonses.com.

Re: [Django] #16281: ContentType.get_object_for_this_type using wrong database for creating object

[Django]

#16281: ContentType.get_object_for_this_type using wrong database for creating
object
-+-
 Reporter:  tfrydrychewicz@… |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:   |  Version:  dev
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, object  | Triage Stage:  Accepted
  get_object_for_this_type,  |
  database, multiple |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * cc: bcail (added)
 * needs_tests:  1 => 0


Comment:

 Actually, the patch in comment number 12, by anonymous, seems to work
 quite well. I added a test and
 [https://github.com/django/django/pull/17479 opened a PR] with that
 change.

-- 
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/0107018bd4a76b8c-8921ce5e-413e-44ab-91cd-1575b065801c-00%40eu-central-1.amazonses.com.

Re: [Django] #34970: Unclear wording in password validator docs

[Django]

#34970: Unclear wording in password validator docs
-+-
 Reporter:  Markus Amalthea  |Owner:  Markus
  Magnuson   |  Amalthea Magnuson
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.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:  0
-+-
Changes (by Natalia Bidart):

 * 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/0107018bd453ac74-f259530d-5154-4b16-9f8f-ecebcfda88e9-00%40eu-central-1.amazonses.com.

Re: [Django] #21183: Filter block on the right covers information in admin

[Django]

#21183: Filter block on the right covers information in admin
-+-
 Reporter:  Vlada Macek  |Owner:  (none)
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin, filter,   | Triage Stage:
  collapse   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia Bidart):

 On going forum discussion:
 https://forum.djangoproject.com/t/ticket-21183-reopening/25269

-- 
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/0107018bd3f8c51a-ab16c9a2-1153-46ba-bc48-beb7d059f8aa-00%40eu-central-1.amazonses.com.

Re: [Django] #34971: Several loggers missing from logging documentation

[Django]

#34971: Several loggers missing from logging documentation
--+
 Reporter:  Ryan Siemens  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  5.0
 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 Simon Charette):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bd3eb23c3-1a67b968-5a08-4121-9813-c72eef6b3e27-00%40eu-central-1.amazonses.com.

Re: [Django] #16281: ContentType.get_object_for_this_type using wrong database for creating object

[Django]

#16281: ContentType.get_object_for_this_type using wrong database for creating
object
-+-
 Reporter:  tfrydrychewicz@… |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:   |  Version:  dev
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  contenttype, object  | Triage Stage:  Accepted
  get_object_for_this_type,  |
  database, multiple |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bcail):

 Here's a similar patch that does the current query, and if it fails, falls
 back to the using the default router. This passes the tests if I fix the
 number of expected queries in one test. If we go this direction, we'd
 probably want to update the `get_all_objects_for_this_type` method as
 well.

 {{{
 diff --git a/django/contrib/contenttypes/models.py
 b/django/contrib/contenttypes/models.py
 index 0d98ed3a4d..2cf08bc85e 100644
 --- a/django/contrib/contenttypes/models.py
 +++ b/django/contrib/contenttypes/models.py
 @@ -2,7 +2,7 @@ from collections import defaultdict

  from django.apps import apps
  from django.db import models
 -from django.db.models import Q
 +from django.db.models import ObjectDoesNotExist, Q
  from django.utils.translation import gettext_lazy as _


 @@ -181,7 +181,10 @@ class ContentType(models.Model):
  method. The ObjectNotExist exception, if thrown, will not be
 caught,
  so code that calls this method should catch it.
  """
 -return
 self.model_class()._base_manager.using(self._state.db).get(**kwargs)
 +try:
 +return
 self.model_class()._base_manager.using(self._state.db).get(**kwargs)
 +except ObjectDoesNotExist:
 +return self.model_class()._base_manager.get(**kwargs)

  def get_all_objects_for_this_type(self, **kwargs):
  """
 diff --git a/tests/contenttypes_tests/test_fields.py
 b/tests/contenttypes_tests/test_fields.py
 index 5510f34cd0..dd1edae834 100644
 --- a/tests/contenttypes_tests/test_fields.py
 +++ b/tests/contenttypes_tests/test_fields.py
 @@ -32,7 +32,7 @@ class GenericForeignKeyTests(TestCase):
  Question.objects.all().delete()

  post = Post.objects.get(pk=post.pk)
 -with self.assertNumQueries(1):
 +with self.assertNumQueries(2):
  self.assertEqual(post.object_id, question_pk)
  self.assertIsNone(post.parent)
  self.assertIsNone(post.parent)
 }}}

-- 
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/0107018bd3db5551-fea37b7e-c9b4-45a1-9f2b-1ff70a953acb-00%40eu-central-1.amazonses.com.

[Django] #34971: Several loggers missing from logging documentation

[Django]

#34971: Several loggers missing from logging documentation
-+
   Reporter:  Ryan Siemens   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  5.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 The [https://docs.djangoproject.com/en/5.0/ref/logging/#loggers logging
 reference] which lists the django built in loggers is missing a couple of
 available logggers.

 - django.dispatch
 - django.contrib.gis
 - django.utils.autoreload

  It would be nice to have these documented as well. 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/0107018bd381af30-7bbd8afa-d1b0-44b9-ab35-084b884d4937-00%40eu-central-1.amazonses.com.

Re: [Django] #34971: Several loggers missing from logging documentation

[Django]

#34971: Several loggers missing from logging documentation
---+--
 Reporter:  Ryan Siemens   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ryan Siemens:

Old description:

> The [https://docs.djangoproject.com/en/5.0/ref/logging/#loggers logging
> reference] which lists the django built in loggers is missing a couple of
> available logggers.
>
> - django.dispatch
> - django.contrib.gis
> - django.utils.autoreload
>
>  It would be nice to have these documented as well. Thanks!

New description:

 The [https://docs.djangoproject.com/en/5.0/ref/logging/#loggers logging
 reference] which lists the django built in loggers is missing a couple of
 available logggers.

 - django.dispatch
 - django.contrib.gis
 - django.utils.autoreload

 It would be nice to have these documented as well. 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/0107018bd3820748-4d9e2e39-7a1c-4510-95f6-346a1875eecc-00%40eu-central-1.amazonses.com.

Re: [Django] #34402: Admin search_fields crashes for inherited model and __iexact lookup.

[Django]

#34402: Admin search_fields crashes for inherited model and __iexact lookup.
+-
 Reporter:  Pavel Pančocha  |Owner:  Rahmat Faisal
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  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
+-

Comment (by Pavel Pančocha):

 Replying to [comment:8 Sarah Boyce]:
 > Can you not define the search_fields here to be `payer_ptr__pk__iexact`
 (as you would when constructing a filter)?
 > I feel like transforming the query for the `search_fields` might be
 surprising as this error is consistent as to if you were to do this with
 `.filter`.
 >
 > (If we want this transforming behaviour I have a patch ready, just not
 convinced it's what we want)


 Sorry, I don't get your comment. The search fields are
 `("pk__iexact",...`. Or what else do you propose? The issue is, that it
 differs in the way it works with "id" and how with "pk".

 If I can help more, let me know please.

-- 
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/0107018bd36fa3c6-3b4ff425-4595-4f6d-a722-613f2bfaf5b0-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

[Django]

#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Ah, right. TBH, the current `NotSupportedError: nondeterministic
 collations are not supported for operator class "varchar_pattern_ops"`
 error is not so bad. Maybe it's enough to add a warning in docs (as you
 suggested).

-- 
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/0107018bd2b48a3b-1dd74804-389b-45a4-be66-d0b174895cd8-00%40eu-central-1.amazonses.com.

Re: [Django] #25173: multi-table inheritance: accessing child object after select_related('child') causes extra query

[Django]

#25173: multi-table inheritance: accessing child object after
select_related('child') causes extra query
-+-
 Reporter:  Sebastian Illing |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ORM, | Triage Stage:  Accepted
  select_related, model inheritance  |
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:

 Please provide a reproducible scenario before reopening a ticket. Tests
 provided by Baptist pass on the current `main` branch (and 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/0107018bd28199aa-3160d58d-a3ee-48cc-8ca1-e743f1eb44fe-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

[Django]

#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Carrick):

 The opposite case works fine because there's no index yet. The user is
 adding an index, so it's expected that the index gets created, and of
 course we need it without `varchar_pattern_ops`.

 In this case though, the user already has a `varchar_pattern_ops` index.
 Postgres offers no way to alter an existing index, it's drop and recreate
 only, so we need to drop the index, change the collation, then add the
 index again but without `varchar_patterm_ops`. My concern here is not that
 it's difficult, it's that we're performing potentially expensive
 operations without informing the user about them (as they don't show up in
 the migration file, or anywhere else). Ideally the user should know they
 can't use `varchar_pattern_ops` with a non-deterministic collation, but
 `db_index` and `unique` are quite opaque about what is actually happening,
 relative to the more explicit `Meta.indexes` and `Meta.constraints`, so
 it's hard for them to know (unless it's very explicitly documented
 somewhere) what the consequences are of changing the collation in this
 scenario.

-- 
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/0107018bd27e7222-d3a810b9-20d9-4789-9d68-1fd12b242049-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

[Django]

#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Tom Carrick]:
 > I agree that it's consistent. What I don't think is a good idea though,
 is dropping and recreating the entire index. This could take a fairly long
 time on some databases, and it can be quite surprising that a change to
 the collation would cause another operation that takes some time.
 >
 > I can have a look though. Maybe we can at least do it concurrently.

 Can we recreate them? For now, we completely skip
 `varchar_pattern_ops`/`text_pattern_ops` indexes when non-deterministic
 `db_collation` is set. Is it not enough to remove them before adding a
 collation?

-- 
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/0107018bd232bf0a-6f95ec26-8f90-4d67-9054-50bf14f3ad05-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

[Django]

#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Carrick):

 I agree that it's consistent. What I don't think is a good idea though, is
 dropping and recreating the entire index. This could take a fairly long
 time on some databases, and it can be quite surprising that a change to
 the collation would cause another operation that takes some time.

 I can have a look though. Maybe we can at least do it concurrently.

-- 
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/0107018bd22da9b8-927402db-01d2-4530-b779-85989f407285-00%40eu-central-1.amazonses.com.

Re: [Django] #25173: multi-table inheritance: accessing child object after select_related('child') causes extra query

[Django]

#25173: multi-table inheritance: accessing child object after
select_related('child') causes extra query
-+-
 Reporter:  Sebastian Illing |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM, | Triage Stage:  Accepted
  select_related, model inheritance  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vapavlov):

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


Comment:

 This ticket is not a duplicate of #16043, and should be reopened.
 Ticket #16043 is about accessing parent model from child, this ticket is
 about the opposite operation.
 This problem still exists in Django 3.2, and probably in later versions
 too.

-- 
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/0107018bd22c883d-d5f08f2d-24e7-4fc3-bf3c-0039f7e4e20d-00%40eu-central-1.amazonses.com.

Re: [Django] #34898: Adding non-deterministic collations to unique CharFields crashes on PostgreSQL.

[Django]

#34898: Adding non-deterministic collations to unique CharFields crashes on
PostgreSQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Tom
 |  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  PostgreSQL   | Triage Stage:  Accepted
  collation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:3 Tom Carrick]:
 > I think handling this in the `schema` module is a really bad idea, as we
 would be dropping and creating an index or constraint without the user's
 knowledge. I don't see another way to handle it.

 I don't think it's that bad. We've already don't create
 `varchar_pattern_ops`/`text_pattern_ops` indexes when non-deterministic
 `db_collation` is set, so removing them before adding a collation would be
 somehow consistent with the current behavior.

-- 
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/0107018bd21fcc20-5e1a6bc6-3c63-4efb-becb-093b72ff53bb-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, I don't think you've explained the issue in enough
 detail to confirm a bug in Django. Please reopen the ticket if you can
 debug your issue and provide a sample project that reproduces the issue.
 Also, be aware that `sync_to_async()` and `async_to_sync()` are not
 compatible with `@sensitive_variables` (as
 [https://docs.djangoproject.com/en/5.0/howto/error-
 reporting/#django.views.decorators.debug.sensitive_variables documented]).

-- 
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/0107018bd20aedbc-9ed1c682-b54e-4af2-9692-f482d3549a91-00%40eu-central-1.amazonses.com.