Re: [Django] #32967: Buggy Migrations when `float("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `float("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  db Q | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for the report, however it looks like a hypothetical issue, what do
 you want to check with such constraint? (`float('nan') != whatever)`.
 `FloatField` uses a proper data type and this should be ensured on a
 database layer without extra constraints. I don't think it's worth
 additional complexity.

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

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

Re: [Django] #32966: time-related _check_fix_default_value() methods can be optimized / simplified

[Django]

#32966: time-related _check_fix_default_value() methods can be optimized /
simplified
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/067.dce35f9eb78af8c244cc22463af17fad%40djangoproject.com.

Re: [Django] #32968: Migration errors from SQLite to Postgres

[Django]

#32968: Migration errors from SQLite to Postgres
-+-
 Reporter:  Song Yang|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  postgres, sqlite,| Triage Stage:
  programmingerror, migration|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Song Yang:

Old description:

> To put my app on Heroku, I am changing my database from SQLite to
> Postgres at the end of my project. Everything works fine locally on
> SQLite. But during `python manage.py migrate --run-syncdb`, I get a
> `ProgrammingError`. I was planning on loading the dumped json later in
> Postgres.
>
> I created a branch on my repo for you to reproduce this bug. The branch
> is `postgres` and the link is https://github.com/XsongyangX/uml-fragment-
> labeling/tree/postgres
>
> Here is the log.
>
> {{{
>
> $ py manage.py migrate --run-syncdb
> Traceback (most recent call last):
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\db\ba
> ckends\utils.py", line 84, in _execute
> return self.cursor.execute(sql, params)
> psycopg2.errors.UndefinedTable: relation "labeling_model" does not exist
> LINE 1: ...del"."classes", "labeling_model"."relations" FROM
> "labeling_...
>  ^
>

> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>   File "C:\Users\Song\Documents\UDEM\master thesis\uml
> data\database\umllabels\m
> anage.py", line 22, in 
> main()
>   File "C:\Users\Song\Documents\UDEM\master thesis\uml
> data\database\umllabels\m
> anage.py", line 18, in main
> execute_from_command_line(sys.argv)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\__init__.py", line 419, in execute_from_command_line
> utility.execute()
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\__init__.py", line 413, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\base.py", line 354, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\base.py", line 398, in execute
> output = self.handle(*args, **options)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\base.py", line 89, in wrapped
> res = handle_func(*args, **kwargs)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\commands\migrate.py", line 75, in handle
> self.check(databases=[database])
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> management\base.py", line 419, in check
> all_issues = checks.run_checks(
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> checks\registry.py", line 76, in run_checks
> new_errors = check(app_configs=app_configs, databases=databases)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> checks\urls.py", line 13, in check_url_config
> return check_resolver(resolver)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\core\
> checks\urls.py", line 23, in check_resolver
> return check_method()
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\urls\
> resolvers.py", line 412, in check
> for pattern in self.url_patterns:
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\utils
> \functional.py", line 48, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\urls\
> resolvers.py", line 598, in url_patterns
> patterns = getattr(self.urlconf_module, "urlpatterns",
> self.urlconf_module)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\utils
> \functional.py", line 48, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
> packages\django\urls\
> resolvers.py", line 591, in urlconf_module
> return import_module(self.urlconf_name)
>   File "C:\Program Files\Python39\lib\importlib\__init__.py", line 

Re: [Django] #32968: Migration errors from SQLite to Postgres

[Django]

#32968: Migration errors from SQLite to Postgres
-+-
 Reporter:  Song Yang|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  postgres, sqlite,| Triage Stage:
  programmingerror, migration|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 This isn't a bug. You have [https://github.com/XsongyangX/uml-fragment-
 labeling/blob/c14a49990b115bd0b8ba74640a7c65da301562d3/labeling/sampler.py#L111
 a query running at the module level] which isn't safe. See
 [https://groups.google.com/g/django-developers/c/7JwWatLfP44 django-
 developers discussion] for more details.

 Next time, please use TicketClosingReasons/UseSupportChannels to debug
 your issue and open an issue here only if you confirm that Django is at
 fault. 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/068.7f8ac03046812d1c3fe2e4c03fce7cff%40djangoproject.com.

[Django] #32968: Migration errors from SQLite to Postgres

[Django]

#32968: Migration errors from SQLite to Postgres
-+-
   Reporter: |  Owner:  nobody
  XsongyangX |
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  Migrations |   Keywords:  postgres, sqlite,
   Severity:  Normal |  programmingerror, migration
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 To put my app on Heroku, I am changing my database from SQLite to Postgres
 at the end of my project. Everything works fine locally on SQLite. But
 during `python manage.py migrate --run-syncdb`, I get a
 `ProgrammingError`. I was planning on loading the dumped json later in
 Postgres.

 I created a branch on my repo for you to reproduce this bug. The branch is
 `postgres` and the link is https://github.com/XsongyangX/uml-fragment-
 labeling/tree/postgres

 Here is the log.

 {{{

 $ py manage.py migrate --run-syncdb
 Traceback (most recent call last):
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\db\ba
 ckends\utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.UndefinedTable: relation "labeling_model" does not exist
 LINE 1: ...del"."classes", "labeling_model"."relations" FROM "labeling_...
  ^


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

 Traceback (most recent call last):
   File "C:\Users\Song\Documents\UDEM\master thesis\uml
 data\database\umllabels\m
 anage.py", line 22, in 
 main()
   File "C:\Users\Song\Documents\UDEM\master thesis\uml
 data\database\umllabels\m
 anage.py", line 18, in main
 execute_from_command_line(sys.argv)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\__init__.py", line 419, in execute_from_command_line
 utility.execute()
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\__init__.py", line 413, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\base.py", line 354, in run_from_argv
 self.execute(*args, **cmd_options)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\base.py", line 398, in execute
 output = self.handle(*args, **options)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\base.py", line 89, in wrapped
 res = handle_func(*args, **kwargs)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\commands\migrate.py", line 75, in handle
 self.check(databases=[database])
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 management\base.py", line 419, in check
 all_issues = checks.run_checks(
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 checks\registry.py", line 76, in run_checks
 new_errors = check(app_configs=app_configs, databases=databases)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 checks\urls.py", line 13, in check_url_config
 return check_resolver(resolver)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\core\
 checks\urls.py", line 23, in check_resolver
 return check_method()
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\urls\
 resolvers.py", line 412, in check
 for pattern in self.url_patterns:
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\utils
 \functional.py", line 48, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\urls\
 resolvers.py", line 598, in url_patterns
 patterns = getattr(self.urlconf_module, "urlpatterns",
 self.urlconf_module)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\utils
 \functional.py", line 48, in __get__
 res = instance.__dict__[self.name] = self.func(instance)
   File "C:\Users\Song\AppData\Roaming\Python\Python39\site-
 packages\django\urls\
 resolvers.py", line 591, in urlconf_module
 return import_module(self.urlconf_name)
   File "C:\Program Files\Python39\lib\importlib\__init__.py", line 127, in
 impor
 t_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1030, in _gcd_import
   File "", line 

Re: [Django] #32965: Django related manager allways choose db_for_read router and fail update/delete

[Django]

#32965: Django related manager allways choose db_for_read router and fail
update/delete
-+-
 Reporter:  Regressor|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  related manager, | Triage Stage:
  db_for_read, exception, db,|  Unreviewed
  router |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Regressor):

 Replying to [comment:1 Mariusz Felisiak]:
 > Thanks for this report, however IMO it's not a bug. It's
 [https://docs.djangoproject.com/en/3.2/topics/db/multi-db/#selecting-a
 -database-to-delete-from documented] that `DELETE` will be executed on the
 same database that was used to retrieve the object, so you need to use
 `using`. I would recommend to use related manager's methods i.e. `clear()`
 instead of chaining `all()` and `delete()`, e.g.
 `instance.mentor_binds.clear()`, and `set()` instead of `update()`, e.g.
 `instance.mentor_binds.set(...)`.

 Oh. It try to delete/update on read database, but this is not a bug
 because it documented. Ok. This automatic database routers has too many
 issues to be used in real life. There was ~8000 lines in our project to
 start working with read replicas and it still doesn't work as expected. It
 looks like we should just disable this config and try aws serverless rds.

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

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

Re: [Django] #32967: Buggy Migrations when `float("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `float("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db Q | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Steven Jin):

 * 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/068.1301197137dd222f80e6b5b52fd1e08d%40djangoproject.com.

Re: [Django] #32967: Buggy Migrations when `float("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `float("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db Q | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Steven Jin):

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


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

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

Re: [Django] #32967: Buggy Migrations when `float("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `float("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db Q | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Steven Jin):

 * cc: Steven Jin (added)
 * status:  assigned => closed
 * has_patch:  0 => 1
 * resolution:   => fixed


Old description:

> When creating a `CheckConstraint` in the form
>
> {{{#!python
> class MyModel(Model):
>   x = FloatField()
>   class Meta:
> constraints = [~CheckConstraint(check=Q(x=float("nan")), name="some
> constraint")]
> }}}
>
> This constraint is removed and added back every time `python manage.py
> makemigrations` is run. This is because the inherited `__eq__` function
> of `Q` objects does not take into account the fact that `float("nan") !=
> float("nan")`.

New description:

 When creating a `CheckConstraint` in the form

 {{{#!python
 class MyModel(Model):
   x = FloatField()
   class Meta:
 constraints = [~CheckConstraint(check=Q(x=float("nan")), name="some
 constraint")]
 }}}

 This constraint is removed and added back every time `python manage.py
 makemigrations` is run. This is because the inherited `__eq__` function of
 `Q` objects does not take into account the fact that `float("nan") !=
 float("nan")`.

 See PR: https://github.com/django/django/pull/14706

--

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

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

Re: [Django] #23895: ResolverMatch with some views is not pickleable

[Django]

#23895: ResolverMatch with some views is not pickleable
--+
 Reporter:  Keryn Knight  |Owner:  zatro
 Type:  Bug   |   Status:  assigned
Component:  Core (URLs)   |  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 zatro):

 * needs_better_patch:  1 => 0


Comment:

 I've now made the changes discussed and squashed the commits.

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

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

Re: [Django] #32967: Buggy Migrations when `float("nan")` in `Q` objects (was: Buggy Migrations when `flota("nan")` in `Q` objects)

[Django]

#32967: Buggy Migrations when `float("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db Q | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

Re: [Django] #32967: Buggy Migrations when `flota("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `flota("nan")` in `Q` objects
-+-
 Reporter:  Steven Jin   |Owner:  Steven
 |  Jin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db Q | 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 Steven Jin:

Old description:

> When creating a `CheckConstraint` in the form
>
> {{{#!python
> class MyModel
>   x = FloatField()
>   class Meta:
> constraints = [~CheckConstraint(check=Q(x=float("nan")), name="some
> constraint")]
> }}}
>
> This constraint is removed and added back every time `python manage.py
> makemigrations` is run. This is because the inherited `__eq__` function
> of `Q` objects does not take into account the fact that `float("nan") !=
> float("nan")`.

New description:

 When creating a `CheckConstraint` in the form

 {{{#!python
 class MyModel(Model):
   x = FloatField()
   class Meta:
 constraints = [~CheckConstraint(check=Q(x=float("nan")), name="some
 constraint")]
 }}}

 This constraint is removed and added back every time `python manage.py
 makemigrations` is run. This is because the inherited `__eq__` function of
 `Q` objects does not take into account the fact that `float("nan") !=
 float("nan")`.

--

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

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

[Django] #32967: Buggy Migrations when `flota("nan")` in `Q` objects

[Django]

#32967: Buggy Migrations when `flota("nan")` in `Q` objects
-+-
   Reporter:  Steven |  Owner:  Steven Jin
  Jin|
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  db Q
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When creating a `CheckConstraint` in the form

 {{{#!python
 class MyModel
   x = FloatField()
   class Meta:
 constraints = [~CheckConstraint(check=Q(x=float("nan")), name="some
 constraint")]
 }}}

 This constraint is removed and added back every time `python manage.py
 makemigrations` is run. This is because the inherited `__eq__` function of
 `Q` objects does not take into account the fact that `float("nan") !=
 float("nan")`.

-- 
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/053.d2df736657b975b78c44d61eb9febaf9%40djangoproject.com.

Re: [Django] #32966: time-related _check_fix_default_value() methods can be optimized / simplified (was: time-related _check_fix_default_value() methods can be simplified)

[Django]

#32966: time-related _check_fix_default_value() methods can be optimized /
simplified
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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
-+-

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

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

[Django] #32966: time-related _check_fix_default_value() methods can be simplified

[Django]

#32966: time-related _check_fix_default_value() methods can be simplified
-+-
   Reporter:  Chris  |  Owner:  Chris Jerdonek
  Jerdonek   |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  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  |
-+-
 I noticed that three of the `_check_fix_default_value()` method
 definitions in `django/db/models/fields/__init__.py` can be simplified.
 Here is one of them:
 
https://github.com/django/django/blob/fe074c96a343530beea50fbdd0803d3e7b739e8e/django/db/models/fields/__init__.py#L1156-L1167

 For example, in each of them, `timezone.now()` is called even when the
 return value isn't needed / won't be used.

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

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

Re: [Django] #32962: Consolidate string concatenations in BaseDatabaseSchemaEditor.column_sql()

[Django]

#32962: Consolidate string concatenations in 
BaseDatabaseSchemaEditor.column_sql()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"809c45ea3c45deedd45e66955ac68ca6bb418e03" 809c45e]:
 {{{
 #!CommitTicketReference repository=""
 revision="809c45ea3c45deedd45e66955ac68ca6bb418e03"
 Fixed #32962 -- Consolidated string concatenations in
 BaseDatabaseSchemaEditor.column_sql().
 }}}

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

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

Re: [Django] #32962: Consolidate string concatenations in BaseDatabaseSchemaEditor.column_sql()

[Django]

#32962: Consolidate string concatenations in 
BaseDatabaseSchemaEditor.column_sql()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"fe074c96a343530beea50fbdd0803d3e7b739e8e" fe074c96]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe074c96a343530beea50fbdd0803d3e7b739e8e"
 Refs #32962 -- Simplified NULL logic in
 BaseDatabaseSchemaEditor._iter_column_sql().
 }}}

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

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

Re: [Django] #32964: Change "setup" to "set up".

[Django]

#32964: Change "setup" to "set up".
-+-
 Reporter:  Nat S Dunn   |Owner:  Mrugakshi
 Type:   |  Thakare
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Nat S Dunn):

 FWIW, I searched through the tutorial, and this was the only instance I
 found. I did not search the rest of the documentation.

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

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

Re: [Django] #32964: Change "setup" to "set up".

[Django]

#32964: Change "setup" to "set up".
-+-
 Reporter:  Nat S Dunn   |Owner:  Mrugakshi
 Type:   |  Thakare
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by David Smith):

 * version:  3.2 => dev
 * stage:  Unreviewed => Accepted


Comment:

 Yes. Setup (noun) is the way something is set up (verb)

 There's more examples of this word being misused in the docs. I think
 'fixed' for this ticket should be to audit for all usages of this phrase
 and adjust where required.

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

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

Re: [Django] #32959: URLValidator test cases can be defined in a Python module

[Django]

#32959: URLValidator test cases can be defined in a Python module
-+-
 Reporter:  Chris Jerdonek   |Owner:  Bal
 Type:   |  Krishna Jha
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Bal Krishna Jha):

 * 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/067.a79b188a98013caefa04823d96bfcc1e%40djangoproject.com.

Re: [Django] #32964: Change "setup" to "set up".

[Django]

#32964: Change "setup" to "set up".
-+-
 Reporter:  Nat S Dunn   |Owner:  mruga7
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 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
-+-
Changes (by mruga7):

 * owner:  nobody => mruga7
 * 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/066.394ad169e85073d59ae5a03f136352db%40djangoproject.com.

Re: [Django] #32962: Consolidate string concatenations in BaseDatabaseSchemaEditor.column_sql()

[Django]

#32962: Consolidate string concatenations in 
BaseDatabaseSchemaEditor.column_sql()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32933: Point users to BoundField.initial instead of Form.get_initial_for_field()

[Django]

#32933: Point users to BoundField.initial instead of 
Form.get_initial_for_field()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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 Carlton Gibson ):

 In [changeset:"aace6c531d5b03b023516b244d87cf5608e24d90" aace6c53]:
 {{{
 #!CommitTicketReference repository=""
 revision="aace6c531d5b03b023516b244d87cf5608e24d90"
 [3.2.x] Fixed #32933 -- Documented BoundField.initial as preferred over
 Form.get_initial_for_field().

 Backport of 6559a55eed09780b30ee3c3636ccf30318622bcf from main
 }}}

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

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

Re: [Django] #32933: Point users to BoundField.initial instead of Form.get_initial_for_field()

[Django]

#32933: Point users to BoundField.initial instead of 
Form.get_initial_for_field()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 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 Carlton Gibson ):

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


Comment:

 In [changeset:"6559a55eed09780b30ee3c3636ccf30318622bcf" 6559a55]:
 {{{
 #!CommitTicketReference repository=""
 revision="6559a55eed09780b30ee3c3636ccf30318622bcf"
 Fixed #32933 -- Documented BoundField.initial as preferred over
 Form.get_initial_for_field().
 }}}

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

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

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

[Django]

#4: Non-nullable blank string-based model field validation doesn't prevent 
or
clean `None`
-+-
 Reporter:  Simon Charette   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * type:  Bug => Cleanup/optimization


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

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

Re: [Django] #27697: JSONField with blank=True is rendered as non-required field in a ModelForm

[Django]

#27697: JSONField with blank=True is rendered as non-required field in a 
ModelForm
---+-
 Reporter:  aruseni|Owner:  Andrew Nester
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  postgres   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Jacob Walls):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * component:  Database layer (models, ORM) => Documentation


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

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

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

[Django]

#4: Non-nullable blank string-based model field validation doesn't prevent 
or
clean `None`
+---
 Reporter:  Simon Charette  |Owner:  Jacob Walls
 Type:  Bug |   Status:  assigned
Component:  Documentation   |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+---
Changes (by Jacob Walls):

 * owner:  nobody => Jacob Walls
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * status:  new => assigned
 * component:  Database layer (models, ORM) => Documentation


Comment:

 [https://groups.google.com/g/django-developers/c/GlYM25fdRnA Per mailing
 list:]
 > It does come up. It _is_ surprising that `blank` has this effect, and
 I'm not convinced it says clearly anywhere how you should approach it…

 Having weighed the possible behavior changes and found them wanting, we're
 looking at documenting the `blank=True` and `null=False` idiom.

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

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

Re: [Django] #27697: JSONField with blank=True is rendered as non-required field in a ModelForm

[Django]

#27697: JSONField with blank=True is rendered as non-required field in a 
ModelForm
-+-
 Reporter:  aruseni  |Owner:  Andrew
 |  Nester
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgres | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

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


Comment:

 Per [https://groups.google.com/g/django-developers/c/GlYM25fdRnA
 discussion] we're going to have a look at clarifying the documentation
 around the blank=True, null=False idiom, and we can do that in #4.

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

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

Re: [Django] #20205: PositiveIntegerfield does not handle empty values well

[Django]

#20205: PositiveIntegerfield does not handle empty values well
-+-
 Reporter:  anonymous|Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

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


Comment:

 Per [https://groups.google.com/g/django-developers/c/GlYM25fdRnA mailing
 list discussion] we cannot envision making behavior changes here because
 we neither want to remove the blankable-and-not-nullable-and-inject-data-
 on-save idiom nor silently cast data in ways a developer might not expect.
 I collected some comments about the blank=True, null=False idiom on #4
 and will reframe it as a documentation task.

 > That said, this is a way for someone to shoot themselves in the foot,
 and the error message could be cleaner. One possible way forward would be
 for Field.get_prep_value to check if the field has empty_strings_allowed =
 False, and if so and if the value is an empty string, to throw some type
 of error with a more meaningful error message. That said, it's not
 strictly necessary, as someone will likely find this very thread from the
 current error message, and realize what the problem is.

 I think the current error (assuming it's in a similar form today to the
 original `invalid literal for int(): ''`) points out that `''` is not an
 int, so in my opinion, I wouldn't add a particularized exception for folks
 using any single particular poor combination of form and model 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/067.2f7e9893c4d2dcb0bca3f5f8ea93a6ac%40djangoproject.com.

Re: [Django] #32953: Enable optional auto-reloading for testserver

[Django]

#32953: Enable optional auto-reloading for testserver
-+-
 Reporter:  Igor Bakutin |Owner:  Igor
 |  Bakutin
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  4.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  testserver reloader  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Thanks for the ticket.

 Replying to [ticket:32953 Igor Bakutin]:
 > `django/core/management/commands/testserver.py:39` has the following
 comment
 >
 > {{{
 > # Run the development server. Turn off auto-reloading because it causes
 > # a strange error -- it causes this handle() method to be called
 > # multiple times.
 > }}}

 However, this comment was added in
 9c55bbdef7f1717aa17f7ca17cb2396522426310 and that doesn't mean that 14
 years later it's still a desirable feature. `testserver` is intended to
 work with a database snapshot (loaded from fixtures) so it can be really
 fragile for any changes in models or migrations. I'm not sure if we can
 support it in a bulletproof way 樂.

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

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

Re: [Django] #32965: Django related manager allways choose db_for_read router and fail update/delete

[Django]

#32965: Django related manager allways choose db_for_read router and fail
update/delete
-+-
 Reporter:  Regressor|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  related manager, | Triage Stage:
  db_for_read, exception, db,|  Unreviewed
  router |
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:

 Thanks for this report, however IMO it's not a bug. It's
 [https://docs.djangoproject.com/en/3.2/topics/db/multi-db/#selecting-a
 -database-to-delete-from documented] that `DELETE` will be executed on the
 same database that was used to retrieve the object, so you need to use
 `using`. I would recommend to use related manager's methods i.e. `clear()`
 instead of chaining `all()` and `delete()`, e.g.
 `instance.mentor_binds.clear()`, and `set()` instead of `update()`, e.g.
 `instance.mentor_binds.set(...)`.

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

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

[Django] #32965: Django related manager allways choose db_for_read router and fail update/delete

[Django]

#32965: Django related manager allways choose db_for_read router and fail
update/delete
-+-
   Reporter:  Regressor  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  related manager,
   Severity:  Normal |  db_for_read, exception, db, router
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 We have a large project running django 3.1.12. It is use aws aurora rds
 cluster for database and we tried to take most of it. Wee need to use read
 replicas to be able fast db overload response. So we made routers, started
 multiple db config, fixed number read replica lag issues and finally got
 error "cannot execute DELETE in a read-only transaction" in simple field
 .delete()

 So. Example: We have a model with a generic relation:
 mentor_binds = GenericRelation('MentorBind',
 object_id_field='parent_object_id',
 content_type_field='parent_content_type')

 And an exception when trying to clean binds:
instance.mentor_binds.all().delete()

 The only workaround is to add .using('default') before .delete() /
 .update()

 I beelive this is a bug in GenericRelatedManager's  _apply_rel_filters()
 method. There is a string in it:

db = self._db or router.db_for_read(self.model, instance=self.instance)

 But I can't say this is the only place with such problem, so I had to add
 .using('default') before all .update() and .delete() - ~400 changes

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

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

Re: [Django] #29063: Replacement Migrations not being executed because of unapplied migrations should raise a warning.

[Django]

#29063: Replacement Migrations not being executed because of unapplied 
migrations
should raise a warning.
-+-
 Reporter:  Julian   |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_tests:  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/073.67c95d49734a496e0d09b7176d51b8a2%40djangoproject.com.

Re: [Django] #32956: Modernise spellings of Web, Email et al

[Django]

#32956: Modernise spellings of Web, Email et al
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 GitHub ):

 In [changeset:"1cba3207867fb168788ad6120770d0398b6b2807" 1cba320]:
 {{{
 #!CommitTicketReference repository=""
 revision="1cba3207867fb168788ad6120770d0398b6b2807"
 Refs #32956 -- Changed "afterwards" to "afterward" in docs and comments.

 This also removes unnecessary comments with the previous spelling.

 AP Stylebook has a short entry to advise the preferred spelling for
 "en-us". "Afterwards" is preferred in British English.
 }}}

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

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

Re: [Django] #30234: Disallow non-uppercase settings in settings.configure()

[Django]

#30234: Disallow non-uppercase settings in settings.configure()
--+
 Reporter:  orlnub123 |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:  settings  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Mariusz Felisiak):

 Replying to [comment:7 k4ml]:
 > Btw the fix is simple actually, add:-
 >
 >
 > del _
 >
 > at the end of settings.py. The localization docs should add this in
 notes.

 It's not an issue in Django or its docs. It's an issue in
 `pytest_djangoapp`. `_` is not a setting name and should not be passed to
 the `.configure()`.

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

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

Re: [Django] #32933: Point users to BoundField.initial instead of Form.get_initial_for_field()

[Django]

#32933: Point users to BoundField.initial instead of 
Form.get_initial_for_field()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30234: Disallow non-uppercase settings in settings.configure()

[Django]

#30234: Disallow non-uppercase settings in settings.configure()
--+
 Reporter:  orlnub123 |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:  settings  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by k4ml):

 Replying to [comment:6 Mariusz Felisiak]:

 > This ticket has nothing to do with using `_` in `settings.py`, it's
 about non-uppercase setting names.

 `_` failed `isupper()` check.

 Btw the fix is simple actually, add:-

 ```
 del _
 ```

 at the end of settings.py. The localization docs should add this in notes.

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

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

Re: [Django] #32743: Migrations don't alter foreign key data types when referencing primary keys in MTI models.

[Django]

#32743: Migrations don't alter foreign key data types when referencing primary 
keys
in MTI models.
-+-
 Reporter:  Mariusz Felisiak |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3d9040a50b160f8b4bb580e09f4120d4979fe29e" 3d9040a5]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d9040a50b160f8b4bb580e09f4120d4979fe29e"
 Refs #32743 -- Fixed recreation of foreign key constraints when altering
 type of referenced primary key with MTI.

 Follow up to 325d7710ce9f6155bb55610ad6b4580d31263557.
 }}}

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

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