Re: [Django] #33608: select_related() to nullable FK with db_constraint=False do not promote OUTER joins.

[Django]

#33608: select_related() to nullable FK with db_constraint=False do not promote
OUTER joins.
-+-
 Reporter:  Mathieu Hinderyckx   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 Mathieu Hinderyckx):

 Replying to [comment:3 Simon Charette]:
 > The question here is should the ORM account for possible integrity
 violations in the first place, lets not forget that `db_constraint` was
 basically introduced as
 
[https://github.com/django/django/commit/b55cde054ee7dd22f93c3522a8ddb1d04193bcac
 some form of shadow option] without in-dept discussion about its desired
 behaviour with regards to violations.
 >
 > How the ORM should account for possible integrity violation was already
 discussed in the past plenty when usage of the MySQL's MyISAM backend (and
 SQLite in older versions) which doesn't support foreign keys was more
 common and caused users to run into this exact issue.
 >
 > Given we've opted not to special case JOIN'ing logic for
 `supports_foreign_keys` in the past I don't see why we should take a
 different stance for `db_constraint=False`.
 >
 > If we allowed
 `Object.objects.filter(remote_object_id=1234).select_related('remote_object')`
 to return `Object` instances what would their `.remote_object` be? A mock
 `RemoteObject(id=1234)` object? Simply `None`? Aren't both approaches
 breaking symmetry with
 `Object.objects.filter(remote_object_id=1234).first().remote_object`
 raising a `RemoteObject.DoesNotExist` exception?

 `Object.objects.filter(remote_object_id=1234).first().remote_object`
 doesn't raise a DoesNotExist exception. It returns null, as it should be.
 First it fetches the Object with `remote_object_id=1234` which exists.
 Secondly, It then accesses the FK field on that Object pointing to a
 RemoteObject, which is null as it does not exist in the remote table
 (hence why the db_constraint=False). That works as expected, just like an
 'ordinary' FK. What doesn't work as expected is that adding a
 select_related() breaks the filter statement. Select_related is an
 optimization, the expectation is that it does the same two steps as before
 but with a single DB query. That isn't the case currently; it silently
 breaks the filtering logic, and doesn't event return the Object at all.

-- 
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/0107017fe3eb506b-9c78b45b-2a2f-4256-aced-1bb52d785980-00%40eu-central-1.amazonses.com.

Re: [Django] #33608: select_related() to nullable FK with db_constraint=False do not promote OUTER joins.

[Django]

#33608: select_related() to nullable FK with db_constraint=False do not promote
OUTER joins.
-+-
 Reporter:  Mathieu Hinderyckx   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Simon, Thanks for the comment. Agreed, `db_constraint = False` in general
 should not be used, except for a few really specific cases. Closing as
 "invalid" as this case is not supported.

-- 
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/0107017fe352e7eb-32a8e1ae-4d89-4c3a-9f4e-9421ece05745-00%40eu-central-1.amazonses.com.

Re: [Django] #33608: select_related() to nullable FK with db_constraint=False do not promote OUTER joins.

[Django]

#33608: select_related() to nullable FK with db_constraint=False do not promote
OUTER joins.
-+-
 Reporter:  Mathieu Hinderyckx   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 The question here is should the ORM account for possible integrity
 violations in the first place, lets not forget that `db_constraint` was
 basically introduced as
 
[https://github.com/django/django/commit/b55cde054ee7dd22f93c3522a8ddb1d04193bcac
 some form of shadow option] without in-dept discussion about its desired
 behaviour with regards to violations.

 How the ORM should account for possible integrity violation was already
 discussed in the past plenty when usage of the MySQL's MyISAM backend (and
 SQLite in older versions) which doesn't support foreign keys was more
 common and caused users to run into this exact issue.

 Given we've opted not to special case JOIN'ing logic for
 `supports_foreign_keys` in the past I don't see why we should take a
 different stance for `db_constraint=False`.

 If we allowed
 `Object.objects.filter(remote_object_id=1234).select_related('remote_object')`
 to return `Object` instances what would their `.remote_object` be? A mock
 `RemoteObject(id=1234)` object? Simply `None`? Aren't both approaches
 breaking symmetry with
 `Object.objects.filter(remote_object_id=1234).first().remote_object`
 raising a `RemoteObject.DoesNotExist` exception?

-- 
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/0107017fe0dd2165-23ea51a8-e8aa-4113-856a-6c7704e6a5e4-00%40eu-central-1.amazonses.com.

Re: [Django] #32129: Confusing documentation on how to get cookie's time until it expires in seconds.

[Django]

#32129: Confusing documentation on how to get cookie's time until it expires in
seconds.
-+-
 Reporter:  Michael  |Owner:  Sarah
 Type:   |  Boyce
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session cookies  | 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 Carlton Gibson ):

 In [changeset:"51374161b003db263068f828537edec50129a098" 5137416]:
 {{{
 #!CommitTicketReference repository=""
 revision="51374161b003db263068f828537edec50129a098"
 [4.0.x] Fixed #32129 -- Adjusted the docs for session expiry helpers.

 Updated the docs for `get_session_cookie_age`, `get_expiry_age`, and
 `get_expiry_date` to clarify their intended usage by session backends
 when saving the session.

 Backport of ae506181f7fb9d9e74f4935686540bef29b60255 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/0107017fe0d8931e-53418ae7-e1d6-49a8-b5a4-0a8d3b69e88c-00%40eu-central-1.amazonses.com.

Re: [Django] #32129: Confusing documentation on how to get cookie's time until it expires in seconds.

[Django]

#32129: Confusing documentation on how to get cookie's time until it expires in
seconds.
-+-
 Reporter:  Michael  |Owner:  Sarah
 Type:   |  Boyce
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  session cookies  | 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 Carlton Gibson ):

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


Comment:

 In [changeset:"ae506181f7fb9d9e74f4935686540bef29b60255" ae50618]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae506181f7fb9d9e74f4935686540bef29b60255"
 Fixed #32129 -- Adjusted the docs for session expiry helpers.

 Updated the docs for `get_session_cookie_age`, `get_expiry_age`, and
 `get_expiry_date` to clarify their intended usage by session backends
 when saving the session.
 }}}

-- 
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/0107017fe083e6e4-a689e0c1-a9a9-4ae1-8ddb-5c4a761601bd-00%40eu-central-1.amazonses.com.

Re: [Django] #32129: Confusing documentation on how to get cookie's time until it expires in seconds.

[Django]

#32129: Confusing documentation on how to get cookie's time until it expires in
seconds.
-+-
 Reporter:  Michael  |Owner:  Sarah
 Type:   |  Boyce
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  session cookies  | 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 Carlton Gibson):

 * needs_better_patch:  1 => 0
 * 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/0107017fe04a30ce-121545aa-1bd1-4398-b573-bf7223adce13-00%40eu-central-1.amazonses.com.

Re: [Django] #33613: createsuperuser does not validate usernames that use a UniqueConstraint.

[Django]

#33613: createsuperuser does not validate usernames that use a UniqueConstraint.
--+
 Reporter:  Lucidiot  |Owner:  Lucidiot
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  4.0
 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 Lucidiot):

 * owner:  nobody => Lucidiot
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

 Done: [https://github.com/django/django/pull/15560 PR]

 Should I update the documentation as well?

-- 
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/0107017fdffb9642-9d393b4c-3f14-4459-aa22-73fb32506e1c-00%40eu-central-1.amazonses.com.

Re: [Django] #33613: createsuperuser does not validate usernames that use a UniqueConstraint. (was: manage.py createsuperuser does not validate usernames that use a UniqueConstraint)

[Django]

#33613: createsuperuser does not validate usernames that use a UniqueConstraint.
--+
 Reporter:  Lucidiot  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.auth  |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this report. It's
 
[https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
 documented] that ''"The field must be unique (i.e., have **unique=True**
 set in its definition)"'', however I agree that we could improve this,
 e.g.:
 {{{#!diff
 diff --git a/django/contrib/auth/management/commands/createsuperuser.py
 b/django/contrib/auth/management/commands/createsuperuser.py
 index 5fffa55a22..0b8c72e866 100644
 --- a/django/contrib/auth/management/commands/createsuperuser.py
 +++ b/django/contrib/auth/management/commands/createsuperuser.py
 @@ -11,6 +11,7 @@ from django.contrib.auth.password_validation import
 validate_password
  from django.core import exceptions
  from django.core.management.base import BaseCommand, CommandError
  from django.db import DEFAULT_DB_ALIAS
 +from django.utils.functional import cached_property
  from django.utils.text import capfirst


 @@ -277,9 +278,18 @@ class Command(BaseCommand):
  else "",
  )

 +@cached_property
 +def username_is_unique(self):
 +if self.username_field.unique:
 +return True
 +for unique_constraint in
 self.UserModel._meta.total_unique_constraints:
 +if len(unique_constraint.fields) == 1 and
 self.username_field.name == unique_constraint.fields[0]:
 +return True
 +return False
 +
  def _validate_username(self, username, verbose_field_name, database):
  """Validate username. If invalid, return a string error
 message."""
 -if self.username_field.unique:
 +if self.username_is_unique:
  try:
 self.UserModel._default_manager.db_manager(database).get_by_natural_key(
  username

 }}}

 Would you like to prepare a patch? (a regression test is also 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/0107017fdf8b5e48-e7c0ad24-9def-486a-b577-fbeaf28faf16-00%40eu-central-1.amazonses.com.

[Django] #33613: manage.py createsuperuser does not validate usernames that use a UniqueConstraint

[Django]

#33613: manage.py createsuperuser does not validate usernames that use a
UniqueConstraint
+
   Reporter:  Lucidiot  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.auth  |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 With a custom User model that uses a `UniqueConstraint` instead of
 `unique=True`, the `manage.py createsuperuser` command does not validate
 usernames at all.

 {{{
 #!python
 class CustomUser(AbstractBaseUser):
 custom_username = models.CharField(max_length=255)
 USERNAME_FIELD = 'custom_username'

 class Meta:
 constraints = [
 models.UniqueConstraint(fields=['custom_username'],
 name='unique_usernames'),
 ]
 }}}

 Running `manage.py createsuperuser` to create a user with a username that
 already exists then results in an IntegrityError:

 {{{
 IntegrityError: duplicate key value violates unique constraint
 "unique_usernames"
 DETAIL:  Key (custom_username)=(foo) already exists.
 }}}

-- 
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/0107017fdf72b6f9-8544fe93-d02b-43cf-8377-b6c05b035956-00%40eu-central-1.amazonses.com.

Re: [Django] #33397: Arithmetic operations on DateField/DateTimeField/DurationField expressions are buggy.

[Django]

#33397: Arithmetic operations on DateField/DateTimeField/DurationField 
expressions
are buggy.
-+-
 Reporter:  Luke Plant   |Owner:  Luke
 |  Plant
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"40b8a6174f001a310aa33f7880db0efeeb04d4c4" 40b8a617]:
 {{{
 #!CommitTicketReference repository=""
 revision="40b8a6174f001a310aa33f7880db0efeeb04d4c4"
 Fixed #33397 -- Corrected resolving output_field for
 DateField/DateTimeField/TimeField/DurationFields.

 This includes refactoring of CombinedExpression._resolve_output_field()
 so it no longer uses the behavior inherited from Expression of guessing
 same output type if argument types match, and instead we explicitly
 define the output type of all supported operations.

 This also makes nonsensical operations involving dates
 (e.g. date + date) raise a FieldError, and adds support for
 automatically inferring output_field for cases such as:
 * date - date
 * date + duration
 * date - duration
 * time + duration
 * time - time
 }}}

-- 
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/0107017fdf63da28-f207c2f1-d9b2-45cf-bf50-ed33fed817ff-00%40eu-central-1.amazonses.com.

Re: [Django] #33397: Arithmetic operations on DateField/DateTimeField/DurationField expressions are buggy.

[Django]

#33397: Arithmetic operations on DateField/DateTimeField/DurationField 
expressions
are buggy.
-+-
 Reporter:  Luke Plant   |Owner:  Luke
 |  Plant
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1efea11808f7b8a3b31445e0c1c7d270f832d965" 1efea118]:
 {{{
 #!CommitTicketReference repository=""
 revision="1efea11808f7b8a3b31445e0c1c7d270f832d965"
 Refs #33397 -- Added register_combinable_fields().
 }}}

-- 
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/0107017fdf63d9df-04a1154c-461f-48e6-8b11-7d87672d36ab-00%40eu-central-1.amazonses.com.

Re: [Django] #33612: Clone db failed in MariaDB 10.7.3. (was: Clone db failed in MySQL8)

[Django]

#33612: Clone db failed in MariaDB 10.7.3.
-+-
 Reporter:  Mohammad Ali |Owner:  nobody
  Mehdizadeh |
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, however it works for me with MariaDB 10.7.3 (you
 don't use MySQL).

-- 
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/0107017fdf51e72f-c3b1d307-40b4-4da1-b46a-c702b4968dde-00%40eu-central-1.amazonses.com.

[Django] #33612: Clone db failed in MySQL8

[Django]

#33612: Clone db failed in MySQL8
-+-
   Reporter:  Mohammad   |  Owner:  nobody
  Ali Mehdizadeh |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In MySQL8, It seems mysqldump value of column-statistics is enabled by
 default but MySQL documentation said another thing.
 Anyway, when I add `--column-statistics=0` to `__clone_db`, I can run
 tests and cloning database works well.
 Database version:`10.7.3-MariaDB-1:10.7.3+maria~focal`
 `(djangoproject) ~/m/d/django ❯❯❯ pip list
 ✘ 1
 Package  Version   Editable project location
  -
 -
 aiohttp  3.8.1
 aiosignal1.2.0
 aiosmtpd 1.4.2
 argon2-cffi  21.3.0
 argon2-cffi-bindings 21.2.0
 asgiref  3.5.0
 async-generator  1.10
 async-timeout4.0.2
 atpublic 3.0.1
 attrs21.4.0
 backports.zoneinfo   0.2.1
 bcrypt   3.2.0
 black22.3.0
 certifi  2021.10.8
 cffi 1.15.0
 charset-normalizer   2.0.12
 click8.1.0
 cryptography 36.0.2
 Deprecated   1.2.13
 Django   4.1.dev20220315120744 /local/path/
 docutils 0.18.1
 frozenlist   1.3.0
 geoip2   4.5.0
 h11  0.13.0
 idna 3.3
 Jinja2   3.1.1
 MarkupSafe   2.1.1
 maxminddb2.2.0
 multidict6.0.2
 mypy-extensions  0.4.3
 mysqlclient  2.1.0
 numpy1.22.3
 outcome  1.1.0
 packaging21.3
 pathspec 0.9.0
 Pillow   9.0.1
 pip  22.0.4
 platformdirs 2.5.1
 psycopg2 2.9.3
 pycparser2.21
 pylibmc  1.6.1
 pymemcache   3.5.1
 pyOpenSSL22.0.0
 pyparsing3.0.7
 PySocks  1.7.1
 pytz 2022.1
 pywatchman   1.4.1
 PyYAML   6.0
 redis4.2.0
 requests 2.27.1
 selenium 4.1.3
 setuptools   61.0.0
 six  1.16.0
 sniffio  1.2.0
 sortedcontainers 2.4.0
 sqlparse 0.4.2
 tblib1.7.0
 tomli2.0.1
 trio 0.20.0
 trio-websocket   0.9.2
 typing_extensions4.1.1
 tzdata   2022.1
 urllib3  1.26.9
 wheel0.37.1
 wrapt1.14.0
 wsproto  1.1.0
 yarl 1.7.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/0107017fdf46b894-a5fc6b85-6d65-436e-a070-de304477aeeb-00%40eu-central-1.amazonses.com.

Re: [Django] #24020: Use expressions in ORM internals

[Django]

#24020: Use expressions in ORM internals
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Anssi
 Type:   |  Kääriäinen
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.8-alpha| 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:"0a3c6fe6b2c43b0bb90cb9df3840dcb70edc22a1" 0a3c6fe6]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a3c6fe6b2c43b0bb90cb9df3840dcb70edc22a1"
 Refs #24020 -- Removed redundant Query.get_loaded_field_names().

 get_loaded_field_names() is no longer called in multiple places
 (see 0c7633178fa9410f102e4708cef979b873bccb76) and it's redundant
 with SQLCompiler.deferred_to_columns().
 }}}

-- 
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/0107017fdf302430-fedb64db-04ec-4b4b-b910-8cc8b5732f97-00%40eu-central-1.amazonses.com.

Re: [Django] #33464: Resolve output_field when combining numeric expressions with MOD operator. (was: Django db expressions doesn't combine MOD)

[Django]

#33464: Resolve output_field when combining numeric expressions with MOD 
operator.
-+-
 Reporter:  gsinghkular  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107017fdf2b0b63-286585ce-cbec-4eed-bdcb-3ad7f2ded9ae-00%40eu-central-1.amazonses.com.

Re: [Django] #33610: Django does not escape the request url in default logging mechanism and may be vulnerable to remote code execution

[Django]

#33610: Django does not escape the request url in default logging mechanism and 
may
be vulnerable to remote code execution
---+--
 Reporter:  DJD|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  4.0
 Severity:  Normal |   Resolution:  needsinfo
 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:   => needsinfo


Comment:

 Please don't report security issues here! Contact
 secur...@djangoproject.com instead.

 It's not clear how logging leads to a code execution but please send a
 full proof of concept to secur...@djangoproject.com and we can review.
 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/0107017fdf2584fa-fe3de741-ee31-49bf-8446-60e12801feba-00%40eu-central-1.amazonses.com.

Re: [Django] #33397: Arithmetic operations on DateField/DateTimeField/DurationField expressions are buggy.

[Django]

#33397: Arithmetic operations on DateField/DateTimeField/DurationField 
expressions
are buggy.
-+-
 Reporter:  Luke Plant   |Owner:  Luke
 |  Plant
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Note that currently `output_field` has limited scope in what it affects:

 - it does not cause a database level `CAST` to be done (see #26650)
 - it controls conversion to Python data types, but that doesn't
 necessarily include validation, so some invalid values for the field may
 be returned.

 Correct behavior for `NULL` was difficult to decide, due to different
 database handling of `NULL`. The current approach is based on lowest
 common denominator behavior i.e. if one of the supported databases is
 raising an error (rather than return `NULL`) for `val  NULL`, then
 Django raises `FieldError`.

 See also [https://github.com/django/django/pull/15271#issue-1091887189
 Luke's description] 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/0107017fdf21df1b-03cdf68f-1f29-4aa2-b49a-5381f61db944-00%40eu-central-1.amazonses.com.

Re: [Django] #33464: Django db expressions doesn't combine MOD

[Django]

#33464: Django db expressions doesn't combine MOD
-+-
 Reporter:  gsinghkular  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Luke Plant):

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


Comment:

 I'm pretty sure the changes committed as part of #33397, while closely
 related, doesn't actually address this case. I think it's best to handle
 this as a separate ticket.

-- 
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/0107017fdee953ad-e32f5687-c95b-4b04-ace1-4505b1638ac4-00%40eu-central-1.amazonses.com.

Re: [Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  New feature  |   Status:  assigned
Component:  Generic views|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  async, asgi, views   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Carlton Gibson


-- 
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/0107017fdee436a7-601056be-431d-48fa-aa61-eef0621a3944-00%40eu-central-1.amazonses.com.

Re: [Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
+
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  Generic views   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  async, asgi, views  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107017fdedd4648-04dcc2b2-1fa7-41f6-8292-f6fb2c0cfe2a-00%40eu-central-1.amazonses.com.

Re: [Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  Generic views   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  async, asgi, views  | 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 Carlton Gibson:

Old description:

> The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-
> views topic docs for Async views] say this about class-based views:
>
> > For a class-based view, this means making its __call__() method an
> async def (not its __init__() or as_view()).
>
> This isn't really appropriate for Django's class-based views:
>
> * We don't implement `__call__()`, rather going via `as_view() — for a
> per-request instance — and then `dispatch()`.
> * Users expect to implement the HTTP method handlers — `get`, `post`, and
> so on — rather than these ''more internal'' bits.
>
> Ideally we'd allow specifying `async def` at the method handler level, to
> allow using `await` in the handler, and writing views such as this:
>
> {{{
> import asyncio
> from django.http import HttpResponse
> from django.views import View
>
> class AsyncView(View):
> async def get(self, request, *args, **kwargs):
> # Perform io-blocking view-logic using await, sleep for
> example.
> await asyncio.sleep(1)
> return HttpResponse("Hello async world!")
> }}}

New description:

 The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-
 views topic docs for Async views] say this about class-based views:

 > For a class-based view, this means making its `__call__()` method an
 async def (not its `__init__()` or `as_view()`).

 This isn't really appropriate for Django's class-based views:

 * We don't implement `__call__()`, rather going via `as_view()` — for a
 per-request instance — and then `dispatch()`.
 * Users expect to implement the HTTP method handlers — `get()`, `post()`,
 and so on — rather than these ''more internal'' bits.

 Ideally we'd allow specifying `async def` at the method handler level, to
 allow using `await` in the handler, and writing views such as this:

 {{{
 import asyncio
 from django.http import HttpResponse
 from django.views import View

 class AsyncView(View):
 async def get(self, request, *args, **kwargs):
 # Perform io-blocking view-logic using await, sleep for
 example.
 await asyncio.sleep(1)
 return HttpResponse("Hello async world!")
 }}}

--

-- 
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/0107017fdecfd641-b3877524-350f-47c5-9e85-6b20cf059bc1-00%40eu-central-1.amazonses.com.

Re: [Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  Generic views   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  async, asgi, views  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Carlton Gibson):

 * component:  HTTP handling => Generic views


-- 
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/0107017fdeced6d3-d30a76b9-4b97-41d4-89f4-e25ad4aa2a67-00%40eu-central-1.amazonses.com.

Re: [Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
+--
 Reporter:  Carlton Gibson  |Owner:  nobody
 Type:  New feature |   Status:  assigned
Component:  HTTP handling   |  Version:  4.0
 Severity:  Normal  |   Resolution:
 Keywords:  async, asgi, views  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Carlton Gibson):

 * cc: Andrew Godwin (added)


Comment:

 [https://github.com/django/django/pull/15559 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/0107017fdeca64b4-44540fa7-a455-424c-9888-13e9ca179f87-00%40eu-central-1.amazonses.com.

[Django] #33611: Allow View subclasses to define async method handlers.

[Django]

#33611: Allow View subclasses to define async method handlers.
-+-
   Reporter:  Carlton|  Owner:  nobody
  Gibson |
   Type:  New| Status:  assigned
  feature|
  Component:  HTTP   |Version:  4.0
  handling   |
   Severity:  Normal |   Keywords:  async, asgi, views
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The current [https://docs.djangoproject.com/en/4.0/topics/async/#async-
 views topic docs for Async views] say this about class-based views:

 > For a class-based view, this means making its __call__() method an async
 def (not its __init__() or as_view()).

 This isn't really appropriate for Django's class-based views:

 * We don't implement `__call__()`, rather going via `as_view() — for a
 per-request instance — and then `dispatch()`.
 * Users expect to implement the HTTP method handlers — `get`, `post`, and
 so on — rather than these ''more internal'' bits.

 Ideally we'd allow specifying `async def` at the method handler level, to
 allow using `await` in the handler, and writing views such as this:

 {{{
 import asyncio
 from django.http import HttpResponse
 from django.views import View

 class AsyncView(View):
 async def get(self, request, *args, **kwargs):
 # Perform io-blocking view-logic using await, sleep for
 example.
 await asyncio.sleep(1)
 return HttpResponse("Hello async world!")
 }}}

-- 
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/0107017fdec7b7db-c6341929-4bcf-475c-b025-6363ac973654-00%40eu-central-1.amazonses.com.