Re: [Django] #373: Add support for multi-columns fields.

[Django]

#373: Add support for multi-columns fields.
-+-
 Reporter:  Jacob|Owner:  Clouds
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Csirmaz Bendegúz):

 I added a patch: https://github.com/django/django/pull/18056
-- 
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/0107018eb6d75a81-ecfe061d-bc5e-4f6b-a8cd-4d6874264b71-00%40eu-central-1.amazonses.com.

Re: [Django] #35359: Got `django.core.exceptions.FieldError` when adding GeneratedField

[Django]

#35359: Got `django.core.exceptions.FieldError` when adding GeneratedField
-+
 Reporter:  wd0517   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  5.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  GeneratedField   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Simon Charette):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted

Comment:

 The auto-detector has to be adapted to make the `AddField` of generated
 field depend on any other `AddField` or `AlterField` of field it
 references through `.expression`. Since `GeneratedField` cannot depend on
 other `GeneratedField` the easier way of doing to avoid introspecting
 `.expression` is likely to make them depend on all other
 non-`GeneratedField` fields being added per model so they are always last.
-- 
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/0107018eb6a16bd1-3bb37cb8-cd79-47c7-9e3d-acbd48aadd54-00%40eu-central-1.amazonses.com.

[Django] #35359: Got `django.core.exceptions.FieldError` when adding GeneratedField

[Django]

#35359: Got `django.core.exceptions.FieldError` when adding GeneratedField
--+
   Reporter:  wd0517  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  5.0
   Severity:  Normal  |   Keywords:  GeneratedField
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Here is an exists model

 {{{
 class Foo1(models.Model):
 age = models.IntegerField()
 }}}

 Then adding GeneratedField


 {{{
 class Foo1(models.Model):
 age = models.IntegerField()
 name = models.CharField(max_length=10)
 lower_name = models.GeneratedField(
 expression=Lower("name"),
 output_field=models.CharField(max_length=11),
 db_persist=True,
 )
 }}}

 Run makemigrations get below file


 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ('temp_django_test', '0006_foo1'),
 ]

 operations = [
 migrations.AddField(
 model_name='foo1',
 name='lower_name',
 field=models.GeneratedField(db_persist=True,
 expression=django.db.models.functions.text.Lower('name'),
 output_field=models.CharField(max_length=11)),
 ),
 migrations.AddField(
 model_name='foo1',
 name='name',
 field=models.CharField(default='a', max_length=10),
 preserve_default=False,
 ),
 ]
 }}}


 Then run migrate, will got error


 {{{
 temp-django-5.0 ❯ python manage.py migrate
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, sessions,
 temp_django_test
 Running migrations:
   Applying temp_django_test.0007_foo1_lower_name_foo1_name...Traceback
 (most recent call last):
   File "/Users/wangdi/Desktop/test_scripts.nosync/temp-
 django-5.0/manage.py", line 22, in 
 main()
   File "/Users/wangdi/Desktop/test_scripts.nosync/temp-
 django-5.0/manage.py", line 18, in main
 execute_from_command_line(sys.argv)
   File "/Users/wangdi/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/Users/wangdi/Desktop/test_scripts.nosync/temp-
 django-5.0/.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 "/Users/wangdi/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/core/management/base.py", line 413, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/core/management/base.py", line 459, in execute
 output = self.handle(*args, **options)
  ^
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/core/management/base.py", line 107, in wrapper
 res = handle_func(*args, **kwargs)
   
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/core/management/commands/migrate.py", line 356, in handle
 post_migrate_state = executor.migrate(
  ^
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 135, in migrate
 state = self._migrate_all_forwards(
 ^^^
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 167, in
 _migrate_all_forwards
 state = self.apply_migration(
 ^
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 252, in apply_migration
 state = migration.apply(state, schema_editor)
 ^
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/db/migrations/migration.py", line 132, in apply
 operation.database_forwards(
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 packages/django/db/migrations/operations/fields.py", line 108, in
 database_forwards
 schema_editor.add_field(
   File "/Users/wd0517/Desktop/test_scripts.nosync/temp-
 django-5.0/.venv/lib/python3.11/site-
 

Re: [Django] #35303: Add async implementations to contrib.auth backends

[Django]

#35303: Add async implementations to contrib.auth backends
--+--
 Reporter:  Jon Janzen|Owner:  Jon Janzen
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:  async auth| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Jon Janzen):

 * 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/0107018eb53ea6f6-bb56a4c8-b5ad-45a7-b6ba-f280942639fe-00%40eu-central-1.amazonses.com.

Re: [Django] #22492: provide a way to prevent database queries on model objects

[Django]

#22492: provide a way to prevent database queries on model objects
-+-
 Reporter:  Chris Jerdonek   |Owner:  Raúl
 |  Cumplido
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  model,queryset,defer,only  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Adam Johnson (added)

Comment:

 FWIW this is being worked on through #28586 which adds modes to configure
 how deferred fields should behave when accessed.
-- 
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/0107018eb51c925f-14e9b237-09e5-4684-aecb-02a43e796cd2-00%40eu-central-1.amazonses.com.

[Django] #35358: Rename BaseConstraint._check to check once the deprecation period

[Django]

#35358: Rename BaseConstraint._check to check once the deprecation period
-+-
   Reporter:  Simon  |  Owner:  nobody
  Charette   |
   Type: | Status:  new
  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  |
-+-
 [https://github.com/django/django/pull/17876/files#r1508517275 Per this
 comment] this is tracking renaming the `BaseConstraint._check` method to
 `check` when the ungoing deprecation period for `BaseConstraint.check`
 (now `.condition`) ends.

 Not sure if there is a better way to categorize this ticket so it doesn't
 fall between the cracks when the deprecation period ends.
-- 
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/0107018eb50a74ca-93c019d7-1e5e-48c0-8c36-ac9af364705c-00%40eu-central-1.amazonses.com.

Re: [Django] #23533: Hook for default QuerySet filtering defined on the QuerySet itself.

[Django]

#23533: Hook for default QuerySet filtering defined on the QuerySet itself.
-+-
 Reporter:  Loic Bistuer |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   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
-+-
Comment (by Simon Charette):

 It'd be good to explore other implementations than that
 `get_initial_queryset` hook as that bi-directionnaly couples Querysets
 with managers (even more than the existing `as_manager` method) and
 prevents reuse of the same queryset class for different managers of the
 same model.

 Approaches such as `CustomQueryset.as_manager(filter=Q(is_active=True))`
 and `CustomQueryset.filter(is_active=True).as_manager()` (this would
 require marking some methods `class_or_instance_method` at
 `__init_subclass__` time to capture the calls and apply them at
 `Manager.contribute_to_class` / app readyness time) seem more valuable as
 they don't require overriding any methods.

 In other words, the `get_initial_queryset` hook saves you from defining a
 manager but you still have to define a method. It also ties your queryset
 class to a single manager usage with seems wrong? What if you want to use
 your custom queryset class with two different filters sets

 {{{#!python
 class FooQueryset(models.QuerySet):
 def is_bar(self):
 return self.filter(bar=True)

 class FooBazQueryset(FooQueryset):
 def get_initial_queryset(self):
 return self.filter(baz=True)

 class FooBatQueryset(FooQueryset):
 def get_initial_queryset(self):
 return self.filter(bat=True)

 class Foo(models.Model):
 bar = models.BooleanField()
 baz = models.BooleanField()
 bat = models.BooleanField()

 objects = FooQueryset.as_manager()
 baz_objects = FooBazQueryset.as_manager()
 bat_objects = FooBatQueryset.as_manager()
 }}}

 Compare that with

 {{{#!python
 class FooQueryset(models.QuerySet):
 def is_bar(self):
 return self.filter(bar=True)

 class Foo(models.Model):
 bar = models.BooleanField()
 baz = models.BooleanField()
 bat = models.BooleanField()

 objects = FooQueryset.as_manager()
 baz_objects = FooQueryset.filter(baz=True).as_manager()
 bat_objects = FooQueryset.filter(bat=True).as_manager()
 }}}
-- 
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/0107018eb4f3b1f0-44d77d7a-9daf-44ac-9df4-b2c26448312a-00%40eu-central-1.amazonses.com.

Re: [Django] #23533: Hook for default QuerySet filtering defined on the QuerySet itself.

[Django]

#23533: Hook for default QuerySet filtering defined on the QuerySet itself.
-+-
 Reporter:  Loic Bistuer |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   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):

 * owner:  nobody => Mariusz Felisiak
 * status:  new => assigned

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018eb46a818d-8730679c-c3a0-43de-96c4-a9ee0595bf12-00%40eu-central-1.amazonses.com.

Re: [Django] #35339: Ordering and filtering a Postgres ArrayAgg with parameters inverts SQL param order

[Django]

#35339: Ordering and filtering a Postgres ArrayAgg with parameters inverts SQL
param order
-+-
 Reporter:  Chris M  |Owner:  Chris M
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres arrayagg| Triage Stage:  Accepted
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_better_patch:  1 => 0

Comment:

 Patch is looking good to me albeit some commit message massaging that
 mergers should be able to handle.
-- 
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/0107018eb450118d-e2d8d329-51b8-45ce-b071-59a0e7a41a6d-00%40eu-central-1.amazonses.com.

Re: [Django] #33671: Migrations crashes when adding/altering collations on indexed columns on Oracle.

[Django]

#33671: Migrations crashes when adding/altering collations on indexed columns on
Oracle.
--+
 Reporter:  Mariusz Felisiak  |Owner:  Mahesh Gupta
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:  oracle collation  | 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/0107018eb390c88d-3c052b9e-a5a6-45b7-a942-2ce8b3b8329f-00%40eu-central-1.amazonses.com.

Re: [Django] #35357: Logger should be able to store extra arguments

[Django]

#35357: Logger should be able to store extra arguments
-+-
 Reporter:  Alexander Nestorov   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  logging, logger, | Triage Stage:
  extra  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Utilities
 * resolution:   => wontfix
 * status:  new => closed

Comment:

 While Django provides a few logging helpers, `logger.error()` is a Python
 APi. I doubt there would be consensus for Django to develop an alternative
 logging API as you've proposed (such code could likely be developed
 outside of Django). If you disagree, you can make your case on the
 DevelopersMailingList.
-- 
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/0107018eb37fe243-7abc82f7-bf63-40ae-b385-ebe994d485a5-00%40eu-central-1.amazonses.com.

Re: [Django] #35357: Logger should be able to store extra arguments

[Django]

#35357: Logger should be able to store extra arguments
-+-
 Reporter:  Alexander Nestorov   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  logging, logger, | Triage Stage:
  extra  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Alexander Nestorov:

Old description:

> I find myself quite often writing multiple `logger.whatever()` statements
> one after another just because I want to log multiple values.
>
> {{{
> logger.error("Foo failed. The bar object looked like")
> logger.error(bar_object) # bar_object is a deep json-like object
> logger.error(f"Retrying with {xyz} thing")
> }}}
>
> It would be nice if Django provided a way to log all values passed to
> `extra`, like this:
>
> {{{
> logger.error("Foo failed. The bar object looked like this. Retrying with
> {xyz} thing", extra={
> "bar_object": bar_object
> })
> }}}
>
> I'm aware that I can create a custom logger inheriting from
> logging.Handler (or the several other ways this can be achieved), but
> IMHO this is such a basic features that it should be included in Django
> itself.

New description:

 I find myself quite often writing multiple `logger.whatever()` statements
 one after another just because I want to log multiple values.

 {{{
 logger.error("Foo failed. The bar object looked like")
 logger.error(bar_object) # bar_object is a deep json-like object
 logger.error(f"Retrying with {xyz} thing")
 }}}

 It would be nice if Django provided a way to log all values passed to
 `extra`, like this:

 {{{
 logger.error(f"Foo failed. The bar object looked like this. Retrying with
 {xyz} thing", extra={
 "bar_object": bar_object
 })
 }}}

 I'm aware that I can create a custom logger inheriting from
 `logging.Handler` (or the several other ways this can be achieved), but
 IMHO this is such a basic feature that it should be included in Django
 itself.

--
-- 
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/0107018eb2c25ea3-debbde43-3354-4a0f-9168-8ee443e944f8-00%40eu-central-1.amazonses.com.

[Django] #35357: Logger should be able to store extra arguments

[Django]

#35357: Logger should be able to store extra arguments
-+-
   Reporter:  Alexander  |  Owner:  nobody
  Nestorov   |
   Type:  New| Status:  new
  feature|
  Component: |Version:
  Uncategorized  |   Keywords:  logging, logger,
   Severity:  Normal |  extra
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I find myself quite often writing multiple `logger.whatever()` statements
 one after another just because I want to log multiple values.

 {{{
 logger.error("Foo failed. The bar object looked like")
 logger.error(bar_object) # bar_object is a deep json-like object
 logger.error(f"Retrying with {xyz} thing")
 }}}

 It would be nice if Django provided a way to log all values passed to
 `extra`, like this:

 {{{
 logger.error("Foo failed. The bar object looked like this. Retrying with
 {xyz} thing", extra={
 "bar_object": bar_object
 })
 }}}

 I'm aware that I can create a custom logger inheriting from
 logging.Handler (or the several other ways this can be achieved), but IMHO
 this is such a basic features that it should be included in Django itself.
-- 
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/0107018eb2be91f9-d1877ce1-7198-49da-a535-56dc01ade21d-00%40eu-central-1.amazonses.com.