Re: [Django] #34878: Autoreload crashes with FORM_RENDERER="django.forms.renderers.TemplatesSetting". (was: Setting FORM_RENDERER="django.forms.renderers.TemplatesSetting" causes template autoreload t

[Django]

#34878: Autoreload crashes with
FORM_RENDERER="django.forms.renderers.TemplatesSetting".
-+
 Reporter:  danjac   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  5.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 Mariusz Felisiak):

 * cc: Priyank Panchal (added)
 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. Would you like to prepare a patch? (a regression
 test is required, sth similar to the
 
`template_tests.test_autoreloader.TemplateReloadTests.test_form_template_reset_template_change_reset_call`
 but with changed `FORM_RENDERER`).
 The following works for me:
 {{{#!diff
 diff --git a/django/template/autoreload.py b/django/template/autoreload.py
 index 01dd564da4..b727d64168 100644
 --- a/django/template/autoreload.py
 +++ b/django/template/autoreload.py
 @@ -39,9 +39,9 @@ def reset_loaders():
  for loader in backend.engine.template_loaders:
  loader.reset()

 -backend = get_default_renderer().engine
 -if isinstance(backend, DjangoTemplates):
 -for loader in backend.engine.template_loaders:
 +renderer = get_default_renderer()
 +if hasattr(renderer, "engine") and isinstance(renderer.engine,
 DjangoTemplates):
 +for loader in renderer.engine.engine.template_loaders:
  loader.reset()


 }}}


 Regression in 439242c5943e16dd5a3a68fadac76e5e723eb323.

-- 
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/0107018ada7e75e4-53166632-b082-4e4d-adfa-0cd7ca736d4d-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  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:"0f9d07398d487868f3ac9bc2e2dd3efef984a49c" 0f9d0739]:
 {{{
 #!CommitTicketReference repository=""
 revision="0f9d07398d487868f3ac9bc2e2dd3efef984a49c"
 [5.0.x] Fixed #34877 -- Fixed migrations crash when adding GeneratedField
 with output_field with params.

 Backport of e7e8eb44a30bcab004a582760752b5eb3fcd6e91 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/0107018ada6b3d8c-3445173a-0d17-4fab-888a-ba6bc5e41cca-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  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:"e7e8eb44a30bcab004a582760752b5eb3fcd6e91" e7e8eb44]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7e8eb44a30bcab004a582760752b5eb3fcd6e91"
 Fixed #34877 -- Fixed migrations crash when adding GeneratedField with
 output_field with params.
 }}}

-- 
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/0107018ada6acabe-a1f41caa-bc92-41b3-b1f8-fbc4de7c0809-00%40eu-central-1.amazonses.com.

Re: [Django] #34878: Setting FORM_RENDERER="django.forms.renderers.TemplatesSetting" causes template autoreload to crash

[Django]

#34878: Setting FORM_RENDERER="django.forms.renderers.TemplatesSetting" causes
template autoreload to crash
-+--
 Reporter:  danjac   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Template system  |  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:  0|UI/UX:  0
-+--
Description changed by danjac:

Old description:

> Running **Python 3.11** and **Django 5.0a1**.
>
> I have the following settings:
>
> {{{#!python
>
> DEBUG = True
>
> FORM_RENDERER = "django.forms.renderers.TemplatesSetting"
>
> TEMPLATES = [
> {
> "BACKEND": "django.template.backends.django.DjangoTemplates",
> "DIRS": [BASE_DIR / "templates"],
> "OPTIONS": {
> "debug": True,
> "context_processors": [
> "django.template.context_processors.debug",
> "django.template.context_processors.request",
> "django.contrib.auth.context_processors.auth",
> "django.template.context_processors.i18n",
> "django.template.context_processors.media",
> "django.template.context_processors.static",
> "django.template.context_processors.tz",
> "django.contrib.messages.context_processors.messages",
> ],
> },
> }
> ]
>
> }}}
>
> This causes the development server to crash whenever a template is saved:
>
> {{{
>   File "python-path/lib/python3.11/site-
> packages/django/template/autoreload.py", line 60, in template_changed
> reset_loaders()
>   File "python-path/lib/python3.11/site-
> packages/django/template/autoreload.py", line 42, in reset_loaders
> backend = get_default_renderer().engine
>   ^
> AttributeError: 'TemplatesSetting' object has no attribute 'engine'
>
> }}}

New description:

 Running **Python 3.11** and **Django 5.0a1**.

 I have the following settings:

 {{{#!python

 DEBUG = True

 FORM_RENDERER = "django.forms.renderers.TemplatesSetting"

 TEMPLATES = [
 {
 "BACKEND": "django.template.backends.django.DjangoTemplates",
 "DIRS": [BASE_DIR / "templates"],
 "OPTIONS": {
 "debug": True,
 "context_processors": [
 "django.template.context_processors.debug",
 "django.template.context_processors.request",
 "django.contrib.auth.context_processors.auth",
 "django.template.context_processors.i18n",
 "django.template.context_processors.media",
 "django.template.context_processors.static",
 "django.template.context_processors.tz",
 "django.contrib.messages.context_processors.messages",
 ],
 },
 }
 ]

 }}}

 This causes the development server (i.e. ''manage.py runserver'') to crash
 whenever a template is saved:

 {{{
   File "python-path/lib/python3.11/site-
 packages/django/template/autoreload.py", line 60, in template_changed
 reset_loaders()
   File "python-path/lib/python3.11/site-
 packages/django/template/autoreload.py", line 42, in reset_loaders
 backend = get_default_renderer().engine
   ^
 AttributeError: 'TemplatesSetting' object has no attribute 'engine'

 }}}

--

-- 
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/0107018ada310141-99c4487c-eba1-4a2c-88a1-5db867afe01b-00%40eu-central-1.amazonses.com.

[Django] #34878: Setting FORM_RENDERER="django.forms.renderers.TemplatesSetting" causes template autoreload to crash

[Django]

#34878: Setting FORM_RENDERER="django.forms.renderers.TemplatesSetting" causes
template autoreload to crash
---+
   Reporter:  danjac   |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Template system  |Version:  5.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|
---+
 Running **Python 3.11** and **Django 5.0a1**.

 I have the following settings:

 {{{#!python

 DEBUG = True

 FORM_RENDERER = "django.forms.renderers.TemplatesSetting"

 TEMPLATES = [
 {
 "BACKEND": "django.template.backends.django.DjangoTemplates",
 "DIRS": [BASE_DIR / "templates"],
 "OPTIONS": {
 "debug": True,
 "context_processors": [
 "django.template.context_processors.debug",
 "django.template.context_processors.request",
 "django.contrib.auth.context_processors.auth",
 "django.template.context_processors.i18n",
 "django.template.context_processors.media",
 "django.template.context_processors.static",
 "django.template.context_processors.tz",
 "django.contrib.messages.context_processors.messages",
 ],
 },
 }
 ]

 }}}

 This causes the development server to crash whenever a template is saved:

 {{{
   File "python-path/lib/python3.11/site-
 packages/django/template/autoreload.py", line 60, in template_changed
 reset_loaders()
   File "python-path/lib/python3.11/site-
 packages/django/template/autoreload.py", line 42, in reset_loaders
 backend = get_default_renderer().engine
   ^
 AttributeError: 'TemplatesSetting' object has no attribute 'engine'

 }}}

-- 
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/0107018ada2e183b-dfb27554-9e9b-46df-bbc3-47e89b6f6af8-00%40eu-central-1.amazonses.com.

Re: [Django] #34875: Use RFC 9106 recommendations in Argon2PasswordHasher

[Django]

#34875: Use RFC 9106 recommendations in Argon2PasswordHasher
-+-
 Reporter:  tecbr|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Florian Apolloner (added)
 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Thanks for the ticket. Django uses the default values for `salt_len` and
 `hash_len`. TBH, I don't see much value in decreasing `time_cost`,
 `memory_cost`, and `parallelism` to the new low-memory profile. It's also
 [https://docs.djangoproject.com/en/stable/topics/auth/passwords/#argon2
 documented] how to adjust parameters to your needs.

 > Why Django does not use these recommendations?

 I'd ask why Django should adapt to the new low-memory profile?

-- 
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/0107018ad9f7fbf6-7810134e-bce9-492f-8b72-a60d58c3f3f6-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paolo Melchiorre):

 Replying to [comment:2 Simon Charette]:
 > Seems like we missed a `db_type_parameters` override

 Thanks again Simon.

 I opened a [https://github.com/django/django/pull/17314 PR] based on your
 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/0107018ad8af3a9b-9e5c787c-f14d-45f1-aa62-ed4c181b4a87-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Melchiorre):

 * owner:  nobody => Paolo Melchiorre
 * status:  new => assigned
 * 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/0107018ad8acd295-5c15b81f-fbb5-45d4-b101-8cc4ba3ca13e-00%40eu-central-1.amazonses.com.

Re: [Django] #34871: Validation of UniqueConstraint with Case() crashes.

[Django]

#34871: Validation of UniqueConstraint with Case() crashes.
-+-
 Reporter:  Andrew Roberts   |Owner:  Francesco
 |  Panico
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.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 Francesco Panico):

 * owner:  (none) => Francesco Panico


-- 
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/0107018ad8490af4-32d64db7-2529-4e62-83bf-ae9a9ea85bf2-00%40eu-central-1.amazonses.com.

Re: [Django] #34871: Validation of UniqueConstraint with Case() crashes.

[Django]

#34871: Validation of UniqueConstraint with Case() crashes.
-+-
 Reporter:  Andrew Roberts   |Owner:  (none)
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.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 Francesco Panico):

 * owner:  nobody => (none)
 * 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/0107018ad8386432-e34554b4-5e85-4405-aa83-5a50f5c057e2-00%40eu-central-1.amazonses.com.

Re: [Django] #34871: Validation of UniqueConstraint with Case() crashes.

[Django]

#34871: Validation of UniqueConstraint with Case() crashes.
-+-
 Reporter:  Andrew Roberts   |Owner:  (none)
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.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 Francesco Panico):

 * owner:  nobody => (none)
 * 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/0107018ad8385fe5-03915bdb-b05a-40e8-8939-7865a4e3fb93-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 Seems like we missed a `db_type_parameters` override

 {{{#!diff
 diff --git a/django/db/models/fields/generated.py
 b/django/db/models/fields/generated.py
 index deb5875638..5fbd4c4fdd 100644
 --- a/django/db/models/fields/generated.py
 +++ b/django/db/models/fields/generated.py
 @@ -161,3 +161,6 @@ def get_internal_type(self):

  def db_parameters(self, connection):
  return self.output_field.db_parameters(connection)
 +
 +def db_type_parameters(self, connection):
 +return self.output_field.db_type_parameters(connection)
 }}}

-- 
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/0107018ad819b097-bcdf6adb-9cb0-4bf8-a255-8770aa60f19a-00%40eu-central-1.amazonses.com.

Re: [Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:
  generated, output_field|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Paolo Melchiorre:

Old description:

> Trying to get SQL code for a migrations I receive a `KeyEorr`
>
> **Model**
>
> {{{#!python
> from decimal import Decimal
> from django.db import models
> from django.db.models import F, Value as V
> from django.db.models.functions import Round
>
> class Item(models.Model):
> price = models.DecimalField(max_digits=7, decimal_places=2)
> vat_price = models.GeneratedField(
> db_persist=True,
> expression=Round(F("price") * V(Decimal("1.22")), 2),
> output_field=models.DecimalField(max_digits=8, decimal_places=2),
> )
> }}}
>
> **Step**
>
> {{{#!bash
> $ python -m manage makemigrations
> $ python -m manage sqlmigrate shop 0001
> }}}
>
> **Traceback**
>
> {{{#!pycon
> Traceback (most recent call last):
>   File "", line 198, in _run_module_as_main
>   File "", line 88, in _run_code
>   File "/home/paulox/Projects/generatedfield/manage.py", line 22, in
> 
> main()
>   File "/home/paulox/Projects/generatedfield/manage.py", line 18, in main
> execute_from_command_line(sys.argv)
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/__init__.py", line 442, in
> execute_from_command_line
> utility.execute()
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/__init__.py", line 436, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/base.py", line 412, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/commands/sqlmigrate.py", line 38, in
> execute
> return super().execute(*args, **options)
>^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/base.py", line 458, in execute
> output = self.handle(*args, **options)
>  ^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/core/management/commands/sqlmigrate.py", line 80, in
> handle
> sql_statements = loader.collect_sql(plan)
>  
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/migrations/loader.py", line 381, in collect_sql
> state = migration.apply(state, schema_editor, collect_sql=True)
> ^^^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/migrations/migration.py", line 132, in apply
> operation.database_forwards(
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/migrations/operations/models.py", line 96, in
> database_forwards
> schema_editor.create_model(model)
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/backends/base/schema.py", line 506, in create_model
> self.deferred_sql.extend(self._model_indexes_sql(model))
>  ^^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/backends/base/schema.py", line 1595, in
> _model_indexes_sql
> output.extend(self._field_indexes_sql(model, field))
>   ^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/backends/postgresql/schema.py", line 63, in
> _field_indexes_sql
> like_index_statement = self._create_like_index_sql(model, field)
>^
>   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
> packages/django/db/backends/postgresql/schema.py", line 88, in
> _create_like_index_sql
> db_type = field.db_type(connection=self.connection)
>   

[Django] #34877: KeyError for output_field in GeneratedField

[Django]

#34877: KeyError for output_field in GeneratedField
-+-
   Reporter:  Paolo  |  Owner:  nobody
  Melchiorre |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.0
  layer (models, ORM)|
   Severity:  Release|   Keywords:  field, database,
  blocker|  generated, output_field
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Trying to get SQL code for a migrations I receive a `KeyEorr`

 **Model**

 {{{#!python
 from decimal import Decimal
 from django.db import models
 from django.db.models import F, Value as V
 from django.db.models.functions import Round

 class Item(models.Model):
 price = models.DecimalField(max_digits=7, decimal_places=2)
 vat_price = models.GeneratedField(
 db_persist=True,
 expression=Round(F("price") * V(Decimal("1.22")), 2),
 output_field=models.DecimalField(max_digits=8, decimal_places=2),
 )
 }}}

 **Step**

 {{{#!bash
 $ python -m manage makemigrations
 $ python -m manage sqlmigrate shop 0001
 }}}

 **Traceback**

 {{{#!pycon
 Traceback (most recent call last):
   File "", line 198, in _run_module_as_main
   File "", line 88, in _run_code
   File "/home/paulox/Projects/generatedfield/manage.py", line 22, in
 
 main()
   File "/home/paulox/Projects/generatedfield/manage.py", line 18, in main
 execute_from_command_line(sys.argv)
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 436, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/base.py", line 412, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/commands/sqlmigrate.py", line 38, in
 execute
 return super().execute(*args, **options)
^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/base.py", line 458, in execute
 output = self.handle(*args, **options)
  ^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/core/management/commands/sqlmigrate.py", line 80, in
 handle
 sql_statements = loader.collect_sql(plan)
  
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/migrations/loader.py", line 381, in collect_sql
 state = migration.apply(state, schema_editor, collect_sql=True)
 ^^^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/migrations/migration.py", line 132, in apply
 operation.database_forwards(
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/migrations/operations/models.py", line 96, in
 database_forwards
 schema_editor.create_model(model)
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/backends/base/schema.py", line 506, in create_model
 self.deferred_sql.extend(self._model_indexes_sql(model))
  ^^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/backends/base/schema.py", line 1595, in
 _model_indexes_sql
 output.extend(self._field_indexes_sql(model, field))
   ^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/backends/postgresql/schema.py", line 63, in
 _field_indexes_sql
 like_index_statement = self._create_like_index_sql(model, field)
^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/backends/postgresql/schema.py", line 88, in
 _create_like_index_sql
 db_type = field.db_type(connection=self.connection)
   ^
   File "/home/paulox/Projects/generatedfield/.venv/lib/python3.11/site-
 packages/django/db/models/fields/__ini

Re: [Django] #34876: Allow password reset token generator to configure timeouts

[Django]

#34876: Allow password reset token generator to configure timeouts
-+-
 Reporter:  Jake Howard  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  4.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 Mariusz Felisiak):

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


Comment:

 Duplicate of #30423.

-- 
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/0107018ad7a87f02-7dcd69f4-1f33-4aaf-b389-e6e86fb00bf0-00%40eu-central-1.amazonses.com.

[Django] #34876: Allow password reset token generator to configure timeouts

[Django]

#34876: Allow password reset token generator to configure timeouts
+
   Reporter:  Jake Howard   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.auth  |Version:  4.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, `django.contrib.auth.tokens.PasswordResetTokenGenerator` uses
 `settings.PASSWORD_RESET_TIMEOUT` for the timeout value for a token.

 In much the same way as the secret key(s) and hash algorithm used are
 configurable through instance attributes, it'd be very convenient if the
 timeout was too (defaulting to `settings.PASSWORD_RESET_TIMEOUT`, of
 course). The token generator is a generic and useful token generator, and
 it can be helpful to use elsewhere. This is the only piece of
 configuration tied to password reset which isn't easily reconfigured.

 A potential extension might be to pass the user into the getter for the
 token generator, allowing the timeout to be configured on a per-user basis
 (eg require admins to use the link sooner). A very niche feature, but
 trivial to implement during this refactor.

-- 
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/0107018ad77f76a5-3d71340b-cb7c-4379-85eb-2243ea64f2f6-00%40eu-central-1.amazonses.com.

[Django] #34875: Use RFC 9106 recommendations in Argon2PasswordHasher

[Django]

#34875: Use RFC 9106 recommendations in Argon2PasswordHasher
+
   Reporter:  tecbr |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.auth  |Version:  4.2
   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 |
+
 The library used by Django for implementation of argon2 (argon2-cffi)
 sinse 21.2.0 (2021-12-08) uses the RFC 9106 low memory profile by default.

 References:
 [https://github.com/hynek/argon2-cffi/issues/101]
 [https://github.com/hynek/argon2-cffi/blob/main/CHANGELOG.md]
 [https://github.com/hynek/argon2-cffi/blob/main/src/argon2/profiles.py]

 Why Django does not use these recommendations?

-- 
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/0107018ad72ac4c3-e4b69390-23e6-433f-b44a-9640547ed666-00%40eu-central-1.amazonses.com.

Re: [Django] #34874: Add table_exists() to optimize checks for django_migrations table. (was: the construction "table_name" in introspection.table_names() is suboptimal)

[Django]

#34874: Add table_exists() to optimize checks for django_migrations table.
-+-
 Reporter:  pinaraf  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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:   => wontfix


Comment:

 > For instance on a PG database with 8800 relations, the query takes 21ms.

 As far as I'm aware, tables introspection is extremely fast on PostgreSQL.
 This is proven by 21ms for 8800 tables.

 > Fixing the migrations recorder to keep the information cached would be a
 quick work around this, but it would still execute the long query at least
 once, but especially with django-tenant-schema it would end up taking tens
 of seconds (at least one call per tenant).

 This is cached in Django 5.0+ (ea8cbca579cc6742e119747fc1eb6ecf90638bce.)

 > I suggest adding an `table_exists(table_name)` function in
 `db.introspection`. Its base implementation could be simply a return
 table_name in self.table_names(), but specific DB engines like PostgreSQL
 could have an optimized variant.

 I don't think it's worth adding for a single (already cached) call.

-- 
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/0107018ad6faecf5-d04bf406-4597-4ad9-9a4b-54a99d625755-00%40eu-central-1.amazonses.com.

Re: [Django] #34320: Renaming fields with truncated names don't remove old constraints on Oracle.

[Django]

#34320: Renaming fields with truncated names don't remove old constraints on
Oracle.
-+-
 Reporter:  Georgi Yanchev   |Owner:  Mohamed
 |  Nabil Rady
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  oracle   | 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:"fec4ed0a250841f41066cbbc9581993ba378d268" fec4ed0a]:
 {{{
 #!CommitTicketReference repository=""
 revision="fec4ed0a250841f41066cbbc9581993ba378d268"
 [4.2.x] Refs #34320 -- Skipped
 SchemaTests.test_rename_field_with_check_to_truncated_name on MariaBD
 10.5.2+.

 This crashes since MariaDB was bumped to 10.5 on Jenkins.
 }}}

-- 
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/0107018ad6e929f8-7f700bc9-75fc-4915-bc33-61575eaa88d1-00%40eu-central-1.amazonses.com.

[Django] #34874: the construction "table_name" in introspection.table_names() is suboptimal

[Django]

#34874: the construction "table_name" in introspection.table_names() is 
suboptimal
-+-
   Reporter:  pinaraf|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  4.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  |
-+-
 On databases with a lot of tables, even in several schemas (with django-
 tenant-schema for instance), the `introspection.table_names()` call can
 take tens of ms to run. For instance on a PG database with 8800 relations,
 the query takes 21ms.
 table_names() is called at least by the migration recorder in order to
 verify the presence of the django_migrations table. It thus slows down
 every migration execution uselessly.
 Fixing the migrations recorder to keep the information cached would be a
 quick work around this, but it would still execute the long query at least
 once, but especially with django-tenant-schema it would end up taking tens
 of seconds (at least one call per tenant).

 I suggest adding an `table_exists(table_name)` function in
 db.introspection. Its base implementation could be simply a `return
 table_name in self.table_names()`, but specific DB engines like PostgreSQL
 could have an optimized variant.
 The SQL query from table_names function modified to add a `relname =
 'XXX'` criteria uses the index on relname and is thus over 20 times
 faster.

-- 
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/0107018ad6add31f-298f08da-291c-4dd8-b45f-a09e6aa3a539-00%40eu-central-1.amazonses.com.

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

[Django]

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
-+
 Reporter:  Chris Woytowitz  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Fabian Pottbäcker):

 I just ran into a similar Issue when reverting migrations on Postgres,
 specifically I have the following condensed and abstracted migration
 history:

 1. Setup:
   1. Create model Author
   2. Create model Book (`author = ForeignKey(Author)`)
 2. Introduce PenNames
   1. Create model PenName
   2. Alter `Book.author` to allow null
   3. Add `author_new = ForgeignKey(PenName, null=True)` to book
   4. RunPython to create PenNames for all authors and set `author_new`
 accordingly (including a corresponding reverse operation)
   5. Drop `Book.author`
   6. Alter `Book.author_new` to prohibit null
   7. Rename `Book.author_new` to `Book.author`
 3. Remove PenNames (for whatever reason)
   1. Some Operation to repopulate `Book.author`
   2. Drop column `Book.author`

 After successfully applying these migrations, reverting to State 1 will
 error when undoing step 2.5, since the index `book_author_id...` was
 already created when undoing step 3.2, but it would be called
 `book_author_new_id...` when applying these migrations forwards.

-- 
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/0107018ad67b7369-fb17d4cd-7332-4232-bde0-511f7b1a53b8-00%40eu-central-1.amazonses.com.

Re: [Django] #31700: Highlight destructive operations in makemigrations output

[Django]

#31700: Highlight destructive operations in makemigrations output
-+---
 Reporter:  Tom Forbes   |Owner:  Amir Karimi
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+---
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


Comment:

 Marking as "needs improvement" per [https://forum.djangoproject.com/t
 /makemigrations-highlighter-interesting-or-noise/24039/6 Adam's comment].

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

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

Re: [Django] #30386: Admin foreign key widgets don't quote keys.

[Django]

#30386: Admin foreign key widgets don't quote keys.
-+-
 Reporter:  Joshua Goodwin   |Owner:
 |  Oluwayemisi Ismail
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_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/0107018ad59b7a03-2562a5a0-bb43-4532-bfdc-c19b7fe2ef20-00%40eu-central-1.amazonses.com.