Re: [Django] #31659: Django loses information regarding the type of grouping columns

[Django]

#31659: Django loses information regarding the type of grouping columns
-+-
 Reporter:  Thodoris |Owner:  felixxm
  Sotiropoulos   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | 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 ):

 In [changeset:"42f5f2d76b19ee36ca659c6141b8a8197387c918" 42f5f2d7]:
 {{{
 #!CommitTicketReference repository=""
 revision="42f5f2d76b19ee36ca659c6141b8a8197387c918"
 [3.1.x] Fixed #31659 -- Made ExpressionWrapper preserve output_field for
 combined expressions.

 Regression in df32fd42b84cc6dbba173201f244491b0d154a63.

 Thanks Simon Charette for the review.

 Backport of aeb8996a6706cad3e96d8221760c1cb408ee7ed9 from master
 }}}

-- 
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.dca713afe78e120c57d7fa042b391459%40djangoproject.com.

Re: [Django] #31659: Django loses information regarding the type of grouping columns

[Django]

#31659: Django loses information regarding the type of grouping columns
-+-
 Reporter:  Thodoris |Owner:  felixxm
  Sotiropoulos   |
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"aeb8996a6706cad3e96d8221760c1cb408ee7ed9" aeb8996a]:
 {{{
 #!CommitTicketReference repository=""
 revision="aeb8996a6706cad3e96d8221760c1cb408ee7ed9"
 Fixed #31659 -- Made ExpressionWrapper preserve output_field for combined
 expressions.

 Regression in df32fd42b84cc6dbba173201f244491b0d154a63.

 Thanks Simon Charette for the review.
 }}}

-- 
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.c6e72e80398d9dfae97b80db1ec48b63%40djangoproject.com.

Re: [Django] #31691: Added ordering support to JSONBAgg.

[Django]

#31691: Added ordering support to JSONBAgg.
--+---
 Reporter:  john-parton   |Owner:  john-parton
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 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 john-parton):

 * owner:  nobody => john-parton
 * status:  new => assigned


Comment:

 Sure. I think I can handle it.

-- 
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/069.03f93ca05457bcc145be4db275a02e03%40djangoproject.com.

Re: [Django] #31693: Add setting to control installed PostgreSQL extensions. (was: disabling migrations and postgresql extensions don't mix well)

[Django]

#31693: Add setting to control installed PostgreSQL extensions.
-+-
 Reporter:  Markus Bertheau  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 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 felixxm):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Database layer (models, ORM) => Migrations


Comment:

 > Maybe extensions should be configured in settings.DATABASES and then
 automatically installed by the postgresql engine.

 `CreateExtension()` is a normal database migration operation, we shouldn't
 treat it differentially. If you don't want to (or cannot) control creating
 extensions with migrations then you can create them directly in a
 database.

-- 
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.9f84f49b99e2949d4e208ec0dfe0b2eb%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hannes Ljungberg):

 * cc: Hannes Ljungberg (added)


-- 
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.c3c6cda3b3036242ba5022fff811b406%40djangoproject.com.

Re: [Django] #31491: dbshell command for MySQL backend uses "passwd" instead of "password".

[Django]

#31491: dbshell command for MySQL backend uses "passwd" instead of "password".
-+-
 Reporter:  Maruti N Sharma  |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell, db, | Triage Stage:  Accepted
  command-line   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  Maruti N Sharma => Hasan Ramezani
 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/13050 New PR]

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

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

Re: [Django] #31649: Support covering exclusion constraints.

[Django]

#31649: Support covering exclusion constraints.
-+-
 Reporter:  felixxm  |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 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 Hannes Ljungberg):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/13049

-- 
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.5501794e383ca528dbc994a01304557d%40djangoproject.com.

Re: [Django] #31693: disabling migrations and postgresql extensions don't mix well

[Django]

#31693: disabling migrations and postgresql extensions don't mix well
-+-
 Reporter:  Markus Bertheau  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by felixxm):

 I'm not sure what you're proposing, TBH.

 > Before that it was possible to disable migrations for all apps with
 MIGRATION_MODULES, mapping every app to None.

 It's still possible.

 > Both don't mix, because when disabling migrations, the extension doesn't
 get installed.

 I don't see any issue in this, it's an expected behavior. We cannot treat
 `CreateExtension()` operations differently.

-- 
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.6be3dba6e454edd4b5fa0215bab3653a%40djangoproject.com.

[Django] #31693: disabling migrations and postgresql extensions don't mix well

[Django]

#31693: disabling migrations and postgresql extensions don't mix well
-+-
   Reporter:  Markus |  Owner:  nobody
  Bertheau   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In [https://code.djangoproject.com/ticket/25388 #25388] a
 [https://docs.djangoproject.com/en/dev/ref/settings/#migrate feature] was
 introduced to disable migrations for test databases. Before that it was
 possible to disable migrations for all apps with MIGRATION_MODULES,
 mapping every app to `None`
 ([https://docs.djangoproject.com/en/dev/ref/settings/#migration-modules as
 explained here]). Other code is used for example in pytest-django
 ([https://github.com/pytest-dev/pytest-
 
django/blob/ee7858af1a80e0091af4d260c0a70e5766c1196a/pytest_django/migrations.py
 here] and [https://github.com/pytest-dev/pytest-
 
django/blob/ee7858af1a80e0091af4d260c0a70e5766c1196a/pytest_django/fixtures.py#L156-L169
 here]) to disable migrations in other ways. All for the speed-up in
 creating a database "directly" (circumventing migrations) as opposed to
 creating it with the migration mechanism.

 Also, [https://docs.djangoproject.com/en/dev/ref/databases/#migration-
 operation-for-adding-extensions here] and
 [https://docs.djangoproject.com/en/dev/ref/contrib/postgres/operations
 /#creating-extension-using-migrations here] it is explained how extensions
 should be installed with a migration operation.

 Both don't mix, because when disabling migrations, the extension doesn't
 get installed. Using features of the extension, for example column types,
 doesn't work.

 As a side note: postgis functionality is provided through a separate
 database engine that provides its own `DatabaseWrapper` that takes care of
 installing the postgis extension, independent of the migration mechanism.

 Maybe extensions should be configured in settings.DATABASES and then
 automatically installed by the postgresql 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/052.55a6de946736d8d73407ea474725b103%40djangoproject.com.

Re: [Django] #31649: Support covering exclusion constraints.

[Django]

#31649: Support covering exclusion constraints.
-+-
 Reporter:  felixxm  |Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 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 Hannes Ljungberg):

 * owner:  (none) => Hannes Ljungberg
 * 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/065.54c5228768b822b3011902d1e805f3ea%40djangoproject.com.

Re: [Django] #31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering

[Django]

#31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by john-parton:

Old description:

> Here's a contrived example:
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=50)
> alias = models.CharField(max_length=50, null=True, blank=True)
> age = models.PositiveSmallIntegerField(default=30)
>

> class Article(models.Model):
> authors = models.ManyToManyField(Author, related_name='articles')
> title = models.CharField(max_length=50)
>

> Article.objects.annotate(
> authors_json=JSONBAgg(
> Func(
> Value('name'), 'name',
> Value('alias'), 'alias',
> function='jsonb_build_object'
> ),
> ordering='age'
> )
> )
> }}}
>
> The ordering kwarg is ignored, but Postgres would have no problem
> understanding the aggregate with an ORDER BY clause
>
> In my code I did the following
>
> {{{#!python
> class OrderableJSONBAgg(OrderableAggMixin, Aggregate):
> function = 'JSONB_AGG'
> template = '%(function)s(%(expressions)s %(ordering)s)'
> output_field = JSONField()
>
> def convert_value(self, value, expression, connection):
> if not value:
> return []
> return value
>

> from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
> }}}
>
> I believe replacing the existing JSONBAgg with this implementation would
> add the feature, with no backwards compat issues.

New description:

 Here's a contrived example:

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=50)
 alias = models.CharField(max_length=50, null=True, blank=True)
 age = models.PositiveSmallIntegerField(default=30)


 class Article(models.Model):
 authors = models.ManyToManyField(Author, related_name='articles')
 title = models.CharField(max_length=50)


 Article.objects.annotate(
 authors_json=JSONBAgg(
 Func(
 Value('name'), 'name',
 Value('alias'), 'alias',
 function='jsonb_build_object'
 ),
 ordering='age'
 )
 )
 }}}

 The ordering kwarg is ignored, but Postgres would have no problem
 understanding the aggregate with an ORDER BY clause

 In my code I did the following

 {{{#!python
 class OrderableJSONBAgg(OrderableAggMixin, Aggregate):
 function = 'JSONB_AGG'
 template = '%(function)s(%(expressions)s %(ordering)s)'
 output_field = JSONField()

 def convert_value(self, value, expression, connection):
 if not value:
 return []
 return value


 from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
 }}}

 I believe replacing the existing JSONBAgg with this implementation would
 add the feature, with no backwards compat issues.

 I would be happy to submit a pull request.

--

-- 
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/069.de73696d06710088c1ef6700a55f0b2a%40djangoproject.com.

Re: [Django] #31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering

[Django]

#31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by john-parton:

Old description:

> Here's a contrived example:
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=50)
> alias = models.CharField(max_length=50, null=True, blank=True)
> age = models.PositiveSmallIntegerField(default=30)
>

> class Article(models.Model):
> authors = models.ManyToManyField(Author, related_name='articles')
> title = models.CharField(max_length=50)
>

> Article.objects.annotate(
> authors_json=JSONBAgg(
> Func(
> Value('name'), 'name',
> Value('alias'), 'alias',
> function='jsonb_build_object'
> ),
> ordering='age'
> )
> )
> }}}
>
> The ordering kwarg is ignored, but Postgres would have no problem
> understanding the aggregate with an ORDER BY clause
>
> In my code I did the following
>
> {{{#!python
> class OrderableJSONBAgg(OrderableAggMixin, Aggregate):
> function = 'JSONB_AGG'
> template = '%(function)s(%(expressions)s %(ordering)s)'
> output_field = JSONField()
>
> def convert_value(self, value, expression, connection):
> if not value:
> return []
> return value
>

> from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
> }}}
>
> I believe adding that mixin is all that would be required to add this
> functionality.

New description:

 Here's a contrived example:

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=50)
 alias = models.CharField(max_length=50, null=True, blank=True)
 age = models.PositiveSmallIntegerField(default=30)


 class Article(models.Model):
 authors = models.ManyToManyField(Author, related_name='articles')
 title = models.CharField(max_length=50)


 Article.objects.annotate(
 authors_json=JSONBAgg(
 Func(
 Value('name'), 'name',
 Value('alias'), 'alias',
 function='jsonb_build_object'
 ),
 ordering='age'
 )
 )
 }}}

 The ordering kwarg is ignored, but Postgres would have no problem
 understanding the aggregate with an ORDER BY clause

 In my code I did the following

 {{{#!python
 class OrderableJSONBAgg(OrderableAggMixin, Aggregate):
 function = 'JSONB_AGG'
 template = '%(function)s(%(expressions)s %(ordering)s)'
 output_field = JSONField()

 def convert_value(self, value, expression, connection):
 if not value:
 return []
 return value


 from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
 }}}

 I believe replacing the existing JSONBAgg with this implementation would
 add the feature, with no backwards compat issues.

--

-- 
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/069.e169b39350e2dc5c5cfb52ea1368c469%40djangoproject.com.

Re: [Django] #31685: Support updating conflicts with QuerySet.bulk_create().

[Django]

#31685: Support updating conflicts with QuerySet.bulk_create().
-+-
 Reporter:  Vitor Pereira|Owner:  Chih Sean
 |  Hsu
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk insert update   | Triage Stage:  Accepted
  upsert |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chih Sean Hsu):

 * cc: Chih Sean Hsu (added)
 * owner:  nobody => Chih Sean Hsu
 * 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/062.ded3e003d9b9d9b6f9adf8159b124cf2%40djangoproject.com.

Re: [Django] #31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering

[Django]

#31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by john-parton:

Old description:

> Here's a contrived example:
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=50)
> alias = models.CharField(max_length=50, null=True, blank=True)
> age = models.PositiveSmallIntegerField(default=30)
>

> class Article(models.Model):
> authors = models.ManyToManyField(Author, related_name='articles')
> title = models.CharField(max_length=50)
>

> Article.objects.annotate(
> authors_json=JSONBAgg(
> Func(
> Value('name'), 'name',
> Value('alias'), 'alias',
> function='jsonb_build_object'
> ),
> ordering='age'
> )
> )
> }}}
>
> The ordering kwarg is ignored, but Postgres would have no problem
> understanding the aggregate with an ORDER BY clause
>
> In my code I did the following
>
> {{{#!python
> class OrderableJSONBAgg(OrderableAggMixin, JSONBAgg)
> pass
>

> from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
> }}}
>
> I believe adding that mixin is all that would be required to add this
> functionality.

New description:

 Here's a contrived example:

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=50)
 alias = models.CharField(max_length=50, null=True, blank=True)
 age = models.PositiveSmallIntegerField(default=30)


 class Article(models.Model):
 authors = models.ManyToManyField(Author, related_name='articles')
 title = models.CharField(max_length=50)


 Article.objects.annotate(
 authors_json=JSONBAgg(
 Func(
 Value('name'), 'name',
 Value('alias'), 'alias',
 function='jsonb_build_object'
 ),
 ordering='age'
 )
 )
 }}}

 The ordering kwarg is ignored, but Postgres would have no problem
 understanding the aggregate with an ORDER BY clause

 In my code I did the following

 {{{#!python
 class OrderableJSONBAgg(OrderableAggMixin, Aggregate):
 function = 'JSONB_AGG'
 template = '%(function)s(%(expressions)s %(ordering)s)'
 output_field = JSONField()

 def convert_value(self, value, expression, connection):
 if not value:
 return []
 return value


 from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
 }}}

 I believe adding that mixin is all that would be required to add this
 functionality.

--

-- 
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/069.a731f5ed9c342a3ac9fbb9b24ee055f3%40djangoproject.com.

Re: [Django] #31007: Make it possible to change the default AutoField to BigAutoField.

[Django]

#31007: Make it possible to change the default AutoField to BigAutoField.
-+-
 Reporter:  Caio Ariede  |Owner:  Caio
 |  Ariede
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by Tom Forbes):

 Proposal: https://groups.google.com/d/msg/django-
 developers/MBPEPKlibGQ/F4i6JPvBAAAJ

-- 
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.38e6f806ece087132683cc927743b690%40djangoproject.com.

[Django] #31692: compilemessages needlessly runs msgfmt on unchanged .po files

[Django]

#31692: compilemessages needlessly runs msgfmt on unchanged .po files
-+-
   Reporter:  cederlys   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (Management commands)  |
   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 have a project where running `django-admin compilemessages` takes 1.75
 seconds. Running it again, when all the `.mo` files already exists and are
 up-to-date, also takes 1.75 seconds.

 I propose that `compilemessages.py` is changed so that it only invokes
 `msgfmt` when it would do anything useful. This can be implemented by
 checking the mtime of the `.po` file and the corresponding `.mo` file. (If
 statting the `.mo` file fails, treat that as if the mtime was 0.) Only
 submit the command to the `executor` if the mtime of the `.po` file is
 greater than that of the `.mo` file.  In effect: don't do anything if the
 `.mo` file is newer than the `.po` file.

 There is one issue with this: the way the code currently uses the
 `is_writable` function. Since it modifies the mtime of the `.mo` file, you
 would have to perform the stat of the `.mo` file before you check if it is
 writable. (Or, you could just remove the `is_writable` function and its
 use. That feature is, in my opinion, of dubious value, and it doesn't
 appear to be documented.)

 After I made the changes above, the runtime in the common case where
 nothing needs to be done was reduced from 1.75 seconds to 0.2 seconds.

 (Unfortunately, I doubt that I will be able to get a Corporate Contributor
 License Agreement signed, so I can unfortunately not contribute my
 change.)

 1.75 seconds may not be much, but when a CI system does it repeatedly, it
 adds up.

-- 
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/051.bae426a4462cb04cc2f506c3b6aaeaaa%40djangoproject.com.

Re: [Django] #31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering

[Django]

#31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering
-+-
 Reporter:  john-parton  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (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
-+-
Description changed by john-parton:

Old description:

> Here's a contrived example:
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=50)
> alias = models.CharField(max_length=50, null=True, blank=True)
> age = models.PositiveSmallIntegerField(default=30)
>

> class Article(models.Model):
> authors = models.ManyToManyField(Author, related_name='articles')
> title = models.CharField(max_length=50)
>

> Article.objects.annotate(
> authors_json=JSONBAgg(
> Func(
> Value('name'), 'name',
> Value('alias'), 'alias',
> ordering='age'
> )
> )
> )
> }}}
>
> The ordering kwarg is ignored, but Postgres would have no problem
> understanding the aggregate with an ORDER BY clause
>
> In my code I did the following
>
> {{{#!python
> class OrderableJSONBAgg(OrderableAggMixin, JSONBAgg)
> pass
>

> from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
> }}}
>
> I believe adding that mixin is all that would be required to add this
> functionality.

New description:

 Here's a contrived example:

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=50)
 alias = models.CharField(max_length=50, null=True, blank=True)
 age = models.PositiveSmallIntegerField(default=30)


 class Article(models.Model):
 authors = models.ManyToManyField(Author, related_name='articles')
 title = models.CharField(max_length=50)


 Article.objects.annotate(
 authors_json=JSONBAgg(
 Func(
 Value('name'), 'name',
 Value('alias'), 'alias',
 function='jsonb_build_object'
 ),
 ordering='age'
 )
 )
 }}}

 The ordering kwarg is ignored, but Postgres would have no problem
 understanding the aggregate with an ORDER BY clause

 In my code I did the following

 {{{#!python
 class OrderableJSONBAgg(OrderableAggMixin, JSONBAgg)
 pass


 from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
 }}}

 I believe adding that mixin is all that would be required to add this
 functionality.

--

-- 
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/069.ecb0359145a300f14932f7c6a1ceea73%40djangoproject.com.

[Django] #31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering

[Django]

#31691: django.contrib.postgres.aggregates.JSONBAgg does not support ordering
-+-
   Reporter:  john-  |  Owner:  nobody
  parton |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Here's a contrived example:

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=50)
 alias = models.CharField(max_length=50, null=True, blank=True)
 age = models.PositiveSmallIntegerField(default=30)


 class Article(models.Model):
 authors = models.ManyToManyField(Author, related_name='articles')
 title = models.CharField(max_length=50)


 Article.objects.annotate(
 authors_json=JSONBAgg(
 Func(
 Value('name'), 'name',
 Value('alias'), 'alias',
 ordering='age'
 )
 )
 )
 }}}

 The ordering kwarg is ignored, but Postgres would have no problem
 understanding the aggregate with an ORDER BY clause

 In my code I did the following

 {{{#!python
 class OrderableJSONBAgg(OrderableAggMixin, JSONBAgg)
 pass


 from myapp.aggregates import OrderableJSONBAgg as JSONBAgg
 }}}

 I believe adding that mixin is all that would be required to add this
 functionality.

-- 
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/054.916b6d8dfead05e53a1a019a519522d1%40djangoproject.com.

Re: [Django] #31690: Document how fuzzy strings are handled by compilemessages

[Django]

#31690: Document how fuzzy strings are handled by compilemessages
-+-
 Reporter:  sebashwa |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  translation i18n | Triage Stage:
  fuzzy compilemessages  |  Unreviewed
  makemessages   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by sebashwa):

 Replying to [comment:1 Claude Paroz]:
 > I'm not sure we should explain `gettext` functionality in Django docs.
 The `use_fuzzy` option in https://docs.djangoproject.com/en/stable/ref
 /django-admin/#django-admin-compilemessages should be a good hint to check
 if something doesn't work the way you think.
 > Maybe linking to https://www.gnu.org/software/gettext/manual/html_node
 /Fuzzy-Entries.html in the `use_fuzzy` explanation?

 I agree that this should rather be a short hint and not a fully fledged
 explanation. But I especially would like to mention the fact somewhere in
 the django docs, that those fuzzy translations are automatically generated
 by makemessages sometimes. So maybe a small hint box here:
 https://docs.djangoproject.com/en/3.0/topics/i18n/translation/#message-
 files stating that this can happen (and maybe when it happens) is the way
 to go? Including the link to the docs at gnu.org you are mentioning would
 work fine here as well.

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

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

Re: [Django] #31689: Warn that bulk_create()'s ignore_conflicts option ignores not only duplicate keys on MySQL. (was: Docs should warn about ignore_conflicts making MySQL tinker with your data)

[Django]

#31689: Warn that bulk_create()'s ignore_conflicts option ignores not only
duplicate keys on MySQL.
--+
 Reporter:  Tobias Krönke |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * stage:  Unreviewed => Accepted


Comment:

 Agreed. It is really unexpected that `ignore_conflicts` ignores also bunch
 of other errors. I don't think we should document this specific use case,
 I would add a short warning (to the
 
[https://docs.djangoproject.com/en/stable/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create
 bulk_create() docs]) that MySQL ignores not only duplicate keys but also
 other errors, with a reference to [https://dev.mysql.com/doc/refman/8.0/en
 /sql-mode.html#ignore-strict-comparison the MySQL docs].

-- 
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/062.0e05a60ebffeb5e848289d04a3d56dd1%40djangoproject.com.

Re: [Django] #31690: Document how fuzzy strings are handled by compilemessages

[Django]

#31690: Document how fuzzy strings are handled by compilemessages
-+-
 Reporter:  sebashwa |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  translation i18n | Triage Stage:
  fuzzy compilemessages  |  Unreviewed
  makemessages   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I'm not sure we should explain `gettext` functionality in Django docs. The
 `use_fuzzy` option in https://docs.djangoproject.com/en/stable/ref/django-
 admin/#django-admin-compilemessages should be a good hint to check if
 something doesn't work the way you think.
 Maybe linking to https://www.gnu.org/software/gettext/manual/html_node
 /Fuzzy-Entries.html in the `use_fuzzy` explanation?

-- 
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.6157fd6a462d8a27d71cdff418b5bc4c%40djangoproject.com.

[Django] #31690: Document how fuzzy strings are handled by compilemessages

[Django]

#31690: Document how fuzzy strings are handled by compilemessages
-+-
   Reporter:  sebashwa   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  3.0
  Documentation  |   Keywords:  translation i18n
   Severity:  Normal |  fuzzy compilemessages makemessages
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I would like to add a passage about how fuzzy strings are handled by the
 compilemessages command here:
 https://docs.djangoproject.com/en/3.0/topics/i18n/translation/#miscellaneous

 I'm pretty new to gettext and didn't know about the concept of fuzzy
 translations. I overlooked / ignored the fuzzy statements, which were
 automatically generated by invoking makemessages. It cost me quite some
 time today to figure out why those translations did not work and I think
 this may have been prevented by some documentation about it.
 I hereby want to reassure that this is a feasible thing to add.

-- 
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/051.491b1c96faff400e0e336b303127a6d7%40djangoproject.com.

Re: [Django] #31667: Avoid passing NULL to the IN lookup

[Django]

#31667: Avoid passing NULL to the IN lookup
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"5776a1660e54a95159164414829738b665c89916" 5776a166]:
 {{{
 #!CommitTicketReference repository=""
 revision="5776a1660e54a95159164414829738b665c89916"
 Fixed #31667 -- Made __in lookup ignore None values.
 }}}

-- 
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.063ec5a8ff0fcd7e142ee1c99501905f%40djangoproject.com.

Re: [Django] #31689: Docs should warn about ignore_conflicts making MySQL tinker with your data

[Django]

#31689: Docs should warn about ignore_conflicts making MySQL tinker with your 
data
-+-
 Reporter:  Tobias Krönke|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.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
-+-

Comment (by Tobias Krönke):

 I was considering this, too. However the description is rather vague not
 really mentioning what "ignoring a failure" could mean and thereby easily
 implying that the row is simply not inserted. If you don't want to pollute
 this method's documentation, it could also be added to
 https://docs.djangoproject.com/en/3.0/ref/databases/#setting-sql-mode to
 make users aware of exceptions to strict mode.

-- 
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/062.6be23ca79f460fa3acaa47c0a136d31d%40djangoproject.com.

Re: [Django] #31689: Docs should warn about ignore_conflicts making MySQL tinker with your data

[Django]

#31689: Docs should warn about ignore_conflicts making MySQL tinker with your 
data
-+-
 Reporter:  Tobias Krönke|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.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
-+-

Comment (by felixxm):

 I'm not sure if the Django documentation is the right place for this
 warning. We cannot document all database caveats.

-- 
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/062.4c9787dbfaccd0061325e2dc898c1911%40djangoproject.com.

Re: [Django] #31689: Docs should warn about ignore_conflicts making MySQL tinker with your data

[Django]

#31689: Docs should warn about ignore_conflicts making MySQL tinker with your 
data
-+-
 Reporter:  Tobias Krönke|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.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
-+-
Changes (by Tobias Krönke):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => 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/062.3b6906206a9980c7530f9d72be499ea7%40djangoproject.com.

[Django] #31689: Docs should warn about ignore_conflicts making MySQL tinker with your data

[Django]

#31689: Docs should warn about ignore_conflicts making MySQL tinker with your 
data
-+
   Reporter:  Tobias Krönke  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 We were caught off guard that MySQL e.g. changes a not nullable date field
 into `-00-00` when trying to bulk insert with `ignore_conflicts=True`
 and `None` as the value for the column. You can read about that behavior
 here:

 - https://www.mysqltutorial.org/mysql-insert-ignore/
 - https://dev.mysql.com/doc/refman/8.0/en/insert.html


 {{{
 With IGNORE, invalid values are adjusted to the closest values and
 inserted;
 }}}

 Of course, you're encouraged to activate strict mode in MySQL (https
 ://django-mysql.readthedocs.io/en/latest/checks.html), but this will not
 help in this specific case:

 https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sql-mode-strict
 {{{
 If strict mode is enabled, dates with zero parts are not permitted and
 inserts produce an error, unless IGNORE is given as well. For INSERT
 IGNORE and UPDATE IGNORE, dates with zero parts are inserted as
 '-00-00'
 }}}

-- 
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/047.16eb3cec4abd6bd9a6ce6ec56419a3a4%40djangoproject.com.

Re: [Django] #31659: Django loses information regarding the type of grouping columns

[Django]

#31659: Django loses information regarding the type of grouping columns
-+-
 Reporter:  Thodoris |Owner:  felixxm
  Sotiropoulos   |
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

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


Comment:

 [https://github.com/django/django/pull/13048 PR]

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

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

Re: [Django] #31660: AttributeError is raised while grouping on reverse relation.

[Django]

#31660: AttributeError is raised while grouping on reverse relation.
-+-
 Reporter:  Tomasz Szymański |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"e2cdbc585a89e130d103307420acf34f232ba699" e2cdbc5]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2cdbc585a89e130d103307420acf34f232ba699"
 [3.0.x] Refs #31660 -- Fixed annotations.tests crash on MySQL.

 Follow up to be7a295141337189b9eceea506489bdfe07f199e.
 }}}

-- 
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/076.67e6f2cfc7b948d40366344ea54336c9%40djangoproject.com.

Re: [Django] #31636: BooleanFieldListFilter doesn't respect field choices.

[Django]

#31636: BooleanFieldListFilter doesn't respect field choices.
---+--
 Reporter:  Maxence G  |Owner:  Jithin Tom
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 [https://github.com/django/django/pull/13047 PR]

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

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

Re: [Django] #31688: Fail to rename and reuse field when using postgres

[Django]

#31688: Fail to rename and reuse field when using postgres
-+--
 Reporter:  Eran Keydar  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.0
 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 felixxm):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Uncategorized => Migrations
 * type:  Uncategorized => Bug


Comment:

 Duplicate of #23577.

-- 
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.2b2b8d6836fd892097ded664d38b3987%40djangoproject.com.

Re: [Django] #28132: File upload crash with "TemporaryFileUploadHandler object has no attribute 'file'" error

[Django]

#28132: File upload crash with "TemporaryFileUploadHandler object has no 
attribute
'file'" error
-+-
 Reporter:  Michal Čihař |Owner:  Michael
 |  Brown
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | 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 ):

 In [changeset:"45ec013116f5d3b9f6a626528e04276b78b688da" 45ec013]:
 {{{
 #!CommitTicketReference repository=""
 revision="45ec013116f5d3b9f6a626528e04276b78b688da"
 [3.1.x] Fixed #28132 -- Made MultiPartParser ignore filenames with
 trailing slash.

 Backport of 36db4dd937ae11c5b687c5d2e5fa3c27e4140001 from master
 }}}

-- 
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/063.3a4a9226998726ae732ec9cae7b17483%40djangoproject.com.

Re: [Django] #28132: File upload crash with "TemporaryFileUploadHandler object has no attribute 'file'" error

[Django]

#28132: File upload crash with "TemporaryFileUploadHandler object has no 
attribute
'file'" error
-+-
 Reporter:  Michal Čihař |Owner:  Michael
 |  Brown
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"36db4dd937ae11c5b687c5d2e5fa3c27e4140001" 36db4dd]:
 {{{
 #!CommitTicketReference repository=""
 revision="36db4dd937ae11c5b687c5d2e5fa3c27e4140001"
 Fixed #28132 -- Made MultiPartParser ignore filenames with trailing slash.
 }}}

-- 
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/063.2b14fe37d7e5541d30e373109ce71732%40djangoproject.com.

Re: [Django] #31667: Avoid passing NULL to the IN lookup (was: Avoid passing NULL to prefetch_related() queries)

[Django]

#31667: Avoid passing NULL to the IN lookup
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-

-- 
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.2f65325c4f52c190d1685a52bd7efe31%40djangoproject.com.