Re: [Django] #31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY mode is enabled on MySQL.

[Django]

#31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY 
mode is
enabled on MySQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ONLY_FULL_GROUP_BY   | Triage Stage:  Accepted
  MySQL MariaDB  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jordan Bae):

 Thanks for giving advise. I will refer your advise.

-- 
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/01070182d3f5905c-4b113de8-fa50-4723-abe8-6bfb75f1bdf9-00%40eu-central-1.amazonses.com.

Re: [Django] #33904: Many-To-Many field is deleted/ignored from internal JavaScript “filter” interface

[Django]

#33904: Many-To-Many field is deleted/ignored from internal JavaScript “filter”
interface
-+-
 Reporter:  Richard Saeuberlich  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  javascript, admin,   | Triage Stage:
  frontend   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carsten Fuchs):

 Ok, many thanks for everyone's help! Sorry for the noise!

-- 
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/01070182d4106102-9afccb79-3c1f-433c-9e84-af0736614c5f-00%40eu-central-1.amazonses.com.

Re: [Django] #33954: NaN can be stored in DecimalField but cannot be retrieved

[Django]

#33954: NaN can be stored in DecimalField but cannot be retrieved
-+-
 Reporter:  Xabier Bello |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Same as ticket https://code.djangoproject.com/ticket/33033, but I managed
> to trigger it anyway:
>
> == Steps to reproduce
>
> * Create a brand new project using python 3.10 and django 4.1 with the
> default sqlite3 backend.
>
> * Create a model with a DecimalField:
> {{{
> class MyModel(models.Model):
> value = models.DecimalField(max_digits=10, decimal_places=5)
> }}}
> * Programmatically create a model instance with value="nan",
> {{{
> obj = MyModel.objects.create(value="nan")
> obj.save()
> }}}
> * Then try to retrieve the object from the database (or refresh from
> database):
> {{{
> MyModel.objects.get(pk=1)
> }}}
>
> == Traceback
> {{{
> Traceback (most recent call last):
>   File "/sandbox/dj/bug/dec/views.py", line 9, in 
> MyModel.objects.get(pk=1)
>   File "/lib64/python3.10/site-packages/django/db/models/manager.py",
> line 85, in manager_method
> return getattr(self.get_queryset(), name)(*args, **kwargs)
>   File "/lib64/python3.10/site-packages/django/db/models/query.py",
> line 646, in get
> num = len(clone)
>   File "/lib64/python3.10/site-packages/django/db/models/query.py",
> line 376, in __len__
> self._fetch_all()
>   File "/lib64/python3.10/site-packages/django/db/models/query.py",
> line 1866, in _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File "/lib64/python3.10/site-packages/django/db/models/query.py",
> line 117, in __iter__
> for row in compiler.results_iter(results):
>   File "/lib64/python3.10/site-
> packages/django/db/models/sql/compiler.py", line 1333, in
> apply_converters
> value = converter(value, expression, connection)
>   File "/lib64/python3.10/site-
> packages/django/db/backends/sqlite3/operations.py", line 344, in
> converter
> return create_decimal(value).quantize(
> TypeError: argument must be int or float
> }}}
> The value "nan" (and maybe "inf" also) skip the validation in
> `DecimalField.to_python`, because is not `None`, and is not instance of
> float. But `decimal.Decimal("nan")` works without triggering the
> exception, so `NaN` gets stored in the DB.

New description:

 Same as ticket https://code.djangoproject.com/ticket/33033, but I managed
 to trigger it anyway:

 == Steps to reproduce

 * Create a brand new project using python 3.10 and django 4.1 with the
 default sqlite3 backend.

 * Create a model with a DecimalField:
 {{{
 class MyModel(models.Model):
 value = models.DecimalField(max_digits=10, decimal_places=5)
 }}}
 * Programmatically create a model instance with value="nan",
 {{{
 obj = MyModel.objects.create(value="nan")
 obj.save()
 }}}
 * Then try to retrieve the object from the database (or refresh from
 database):
 {{{
 MyModel.objects.get(pk=1)
 }}}

 == Traceback
 {{{
 Traceback (most recent call last):
   File "/sandbox/dj/bug/dec/views.py", line 9, in 
 MyModel.objects.get(pk=1)
   File "/lib64/python3.10/site-packages/django/db/models/manager.py",
 line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/lib64/python3.10/site-packages/django/db/models/query.py",
 line 646, in get
 num = len(clone)
   File "/lib64/python3.10/site-packages/django/db/models/query.py",
 line 376, in __len__
 self._fetch_all()
   File "/lib64/python3.10/site-packages/django/db/models/query.py",
 line 1866, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "/lib64/python3.10/site-packages/django/db/models/query.py",
 line 117, in __iter__
 for row in compiler.results_iter(results):
   File "/lib64/python3.10/site-
 packages/django/db/models/sql/compiler.py", line 1333, in apply_converters
 value = converter(value, expression, connection)
   File "/lib64/python3.10/site-
 packages/django/db/backends/sqlite3/operations.py", line 344, in converter
 return create_decimal(value).quantize(
 TypeError: argument must be int or float
 }}}
 The value "na

Re: [Django] #33938: Defining the "through" model in a many-to-many field in another app causes "AttributeError: 'str' object has no attribute '_meta'" on migration

[Django]

#33938: Defining the "through" model in a many-to-many field in another app 
causes
"AttributeError: 'str' object has no attribute '_meta'" on migration
-+-
 Reporter:  bryan.af7|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration many-to-   | Triage Stage:  Ready for
  many bug   |  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:"c9ebd5b7aa82c2958c59786a9925037602ab00b8" c9ebd5b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="c9ebd5b7aa82c2958c59786a9925037602ab00b8"
 [4.1.x] Fixed #33938 -- Fixed migration crash for m2m with a through model
 in another app.

 Regression in aa4acc164d1247c0de515c959f7b09648b57dc42.

 Thanks bryangeplant for the report.

 Backport of 71902e0d9f93670c4f93ff9d66095b0e571be74b 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/01070182d4226e4f-64c7eac2-1892-45e5-90bc-5fd6dc8fc8dc-00%40eu-central-1.amazonses.com.

Re: [Django] #33938: Defining the "through" model in a many-to-many field in another app causes "AttributeError: 'str' object has no attribute '_meta'" on migration

[Django]

#33938: Defining the "through" model in a many-to-many field in another app 
causes
"AttributeError: 'str' object has no attribute '_meta'" on migration
-+-
 Reporter:  bryan.af7|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migration many-to-   | Triage Stage:  Ready for
  many bug   |  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:"71902e0d9f93670c4f93ff9d66095b0e571be74b" 71902e0]:
 {{{
 #!CommitTicketReference repository=""
 revision="71902e0d9f93670c4f93ff9d66095b0e571be74b"
 Fixed #33938 -- Fixed migration crash for m2m with a through model in
 another app.

 Regression in aa4acc164d1247c0de515c959f7b09648b57dc42.

 Thanks bryangeplant for the report.
 }}}

-- 
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/01070182d42271ac-111d75d4-fd1e-4232-a233-4e1fbdc864db-00%40eu-central-1.amazonses.com.

Re: [Django] #33954: "NaN" can be stored in DecimalField but cannot be retrieved (was: NaN can be stored in DecimalField but cannot be retrieved)

[Django]

#33954: "NaN" can be stored in DecimalField but cannot be retrieved
-+-
 Reporter:  Xabier Bello |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.1
  (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):

 * status:  closed => new
 * type:  Bug => Cleanup/optimization
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 > Notice that I'm using the Model validation, if I'm not mistaken and it
 refers to creating objects with `MyModel.objects.create`

 Not really, `.create()` and `.save()` don't call `full_clean()` (see
 [https://docs.djangoproject.com/en/4.1/ref/models/instances/#validating-
 objects docs]). We added extra guards in #33033 because on some databases
 (SQLite and PostgreSQL) `NaN` values are accepted without raising any
 database-level errors.

 I agree that we should add the same checks for `"nan"` strings.

-- 
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/01070182d4507bd5-68adbcf6-ec16-4dac-9537-ffd79ae9074e-00%40eu-central-1.amazonses.com.

Re: [Django] #24179: FilteredSelectMultiple widget - add filter field to the right column.

[Django]

#24179: FilteredSelectMultiple widget - add filter field to the right column.
-+-
 Reporter:  gdmka|Owner:  Gav
 |  O'Connor
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FilteredSelectMultiple,|
  filter_horizontal, UI  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
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/01070182d4c340c8-71c51697-da53-444e-b644-f10d3e533e2c-00%40eu-central-1.amazonses.com.

Re: [Django] #33941: AutoField -> BigAutoField causes PostgreSQL sequence value changes

[Django]

#33941: AutoField -> BigAutoField causes PostgreSQL sequence value changes
-+-
 Reporter:  Barry Johnson|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  BigAutoField,| Triage Stage:
  sequence   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Thanks for this ticket, however Django 3.2 is in extended support and
 doesn't receive bugfixes anymore (except security patches). Moreover,
 Django 4.1+ should not be affected anymore as it uses `IDENTITY` columns
 instead of `SERIAL`s and doesn't set sequence values (see
 2eea361eff58dd98c409c5227064b901f41bd0d6).

 Fixed by 2eea361eff58dd98c409c5227064b901f41bd0d6.

-- 
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/01070182d4e48ccb-ab64d76c-a992-4a49-ac00-a3c58deae689-00%40eu-central-1.amazonses.com.

Re: [Django] #30511: Support Identity columns on PostgreSQL.

[Django]

#30511: Support Identity columns on PostgreSQL.
-+-
 Reporter:  Michael Kany |Owner:  Florian
 |  Apolloner
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  postgres generated   | Triage Stage:  Ready for
  identity   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 #33941 was fixed by 2eea361eff58dd98c409c5227064b901f41bd0d6.

-- 
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/01070182d4e535d9-2efd10f0-599b-4d31-bee2-99fcdd4d9bf1-00%40eu-central-1.amazonses.com.

Re: [Django] #31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY mode is enabled on MySQL.

[Django]

#31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY 
mode is
enabled on MySQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ONLY_FULL_GROUP_BY   | Triage Stage:  Accepted
  MySQL MariaDB  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jordan Bae):

 Hi, Mariusz Felisiak.

 I don't understand fully `GROUP BY optimization` meaning.
 Do you mean when you add column which doesn't include on `group by` into
 `select list`, if it is functionally dependent, it work well?

 ex)
 {{{
 SELECT
 id,
 name,
 count(*)
 FROM
 aggregation_book
 GROUP BY
 id
 }}}

 when i check query with
 
`tests.aggregation.tests.AggregateTestCase.test_aggregation_subquery_annotation_multivalued().`,
 author_qs create below query.

 {{{
 SELECT
 `aggregation_author`.`id`,
 `aggregation_author`.`name`,
 `aggregation_author`.`age`,
 `aggregation_author`.`rating`,
 (
 SELECT
 U0. `id`
 FROM
 `aggregation_author` U0
 INNER JOIN `aggregation_book_authors` U1 ON (U0.
 `id` = U1. `author_id`)
 INNER JOIN `aggregation_book` U2 ON (U1. `book_id`
 = U2. `id`)
 WHERE (U2. `name` = (`aggregation_book`.`name`)
 AND U0. `id` = (`aggregation_author`.`id`))
 ) AS `subquery_id`,
 COUNT(`aggregation_book_authors`.`book_id`) AS `count`
 FROM
 `aggregation_author`
 LEFT OUTER JOIN `aggregation_book_authors` ON
 (`aggregation_author`.`id` = `aggregation_book_authors`.`author_id`)
 LEFT OUTER JOIN `aggregation_book` ON
 (`aggregation_book_authors`.`book_id` = `aggregation_book`.`id`)
 GROUP BY
 `aggregation_author`.`id`
 ORDER BY
 NULL

 }}}

 And MySQL return error with below comments.

 {{{
 Query 1 ERROR: Expression #5 of SELECT list is not in GROUP BY clause and
 contains nonaggregated column 'djangosample.aggregation_book.name' which
 is not functionally dependent on columns in GROUP BY clause; this is
 incompatible with sql_mode=only_full_group_by
 }}}

 It is because of aggregation_book's column.
 if we changed query like below, it works.

 {{{
 SELECT
 `aggregation_author`.`id`,
 `aggregation_author`.`name`,
 `aggregation_author`.`age`,
 `aggregation_author`.`rating`,
 (
 SELECT
 U0. `id`
 FROM
 `aggregation_author` U0
 INNER JOIN `aggregation_book_authors` U1 ON (U0.
 `id` = U1. `author_id`)
 INNER JOIN `aggregation_book` U2 ON (U1. `book_id`
 = U2. `id`)
 WHERE (U0. `id` = (`aggregation_author`.`id`))
 ) AS `subquery_id`,
 COUNT(`aggregation_book_authors`.`book_id`) AS `count`
 FROM
 `aggregation_author`
 LEFT OUTER JOIN `aggregation_book_authors` ON
 (`aggregation_author`.`id` = `aggregation_book_authors`.`author_id`)
 LEFT OUTER JOIN `aggregation_book` ON
 (`aggregation_book_authors`.`book_id` = `aggregation_book`.`id`)
 GROUP BY
 `aggregation_author`.`id`
 ORDER BY
 NULL
 }}}

 I think if we exclude `book_name` filter, it will work with MySQ, too. or
 we can add new testcases.

 And i didn't understand why Simon said allows_group_by_pk feature flag
 return "ONLY_FULL_GROUP_BY" not in self.connection.sql_mode instead of
 always True. I think we can use allows_group_by_pk feature when there is
 no other table's column in the `select list` and `having` and `order by`.

-- 
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/01070182d5e2d63a-5de50a28-e3f4-476c-953d-44e023ff8146-00%40eu-central-1.amazonses.com.

Re: [Django] #31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY mode is enabled on MySQL.

[Django]

#31331: GROUP BY optimization doesn't work properly when ONLY_FULL_GROUP_BY 
mode is
enabled on MySQL.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ONLY_FULL_GROUP_BY   | Triage Stage:  Accepted
  MySQL MariaDB  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jordan Bae):

 And i checked in the postgresql it generate query like below.

 {{{
 SELECT
 "aggregation_author"."id",
 "aggregation_author"."name",
 "aggregation_author"."age",
 "aggregation_author"."rating",
 (
 SELECT
 U0. "id"
 FROM
 "aggregation_author" U0
 INNER JOIN "aggregation_book_authors" U1 ON (U0.
 "id" = U1. "author_id")
 INNER JOIN "aggregation_book" U2 ON (U1. "book_id"
 = U2. "id")
 WHERE (U2. "name" = ("aggregation_book"."name")
 AND U0. "id" = ("aggregation_author"."id"))) AS
 "subquery_id", COUNT("aggregation_book_authors"."book_id") AS "count"
 FROM
 "aggregation_author"
 LEFT OUTER JOIN "aggregation_book_authors" ON
 ("aggregation_author"."id" = "aggregation_book_authors"."author_id")
 LEFT OUTER JOIN "aggregation_book" ON
 ("aggregation_book_authors"."book_id" = "aggregation_book"."id")
 GROUP BY
 "aggregation_author"."id",
 (
 SELECT
 U0. "id"
 FROM
 "aggregation_author" U0
 INNER JOIN "aggregation_book_authors" U1 ON (U0.
 "id" = U1. "author_id")
 INNER JOIN "aggregation_book" U2 ON (U1. "book_id"
 = U2. "id")
 WHERE (U2. "name" = ("aggregation_book"."name")
 AND U0. "id" = ("aggregation_author"."id")))
 }}}

 And in mysql, The same error occurs when subquery is added to group by
 like postgresql.

 {{{
 SELECT
 `aggregation_author`.`id`,
 `aggregation_author`.`name`,
 `aggregation_author`.`age`,
 `aggregation_author`.`rating`,
 (
 SELECT
 U0. `id`
 FROM
 `aggregation_author` U0
 INNER JOIN `aggregation_book_authors` U1 ON (U0.
 `id` = U1. `author_id`)
 INNER JOIN `aggregation_book` U2 ON (U1. `book_id`
 = U2. `id`)
 WHERE (U2. `name` = (`aggregation_book`.`name`)
 AND U0. `id` = (`aggregation_author`.`id`))
 ) AS `subquery_id`,
 COUNT(`aggregation_book_authors`.`book_id`) AS `count`
 FROM
 `aggregation_author`
 LEFT OUTER JOIN `aggregation_book_authors` ON
 (`aggregation_author`.`id` = `aggregation_book_authors`.`author_id`)
 LEFT OUTER JOIN `aggregation_book` ON
 (`aggregation_book_authors`.`book_id` = `aggregation_book`.`id`)
 GROUP BY
 `aggregation_author`.`id`,
 (
 SELECT
 U0. `id`
 FROM
 `aggregation_author` U0
 INNER JOIN `aggregation_book_authors` U1 ON (U0.
 `id` = U1. `author_id`)
 INNER JOIN `aggregation_book` U2 ON (U1. `book_id`
 = U2. `id`)
 WHERE (U2. `name` = (`aggregation_book`.`name`)
 AND U0. `id` = (`aggregation_author`.`id`))
 )

 Query 1 ERROR: Expression #5 of SELECT list is not in GROUP BY clause and
 contains nonaggregated column 'djangosample.aggregation_book.name' which
 is not functionally dependent on columns in GROUP BY clause; this is
 incompatible with sql_mode=only_full_group_by
 }}}

 I think it's some kind issue on mysql logic for functionally dependent
 check.

-- 
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/01070182d5f8c7b0-41b98395-dcd1-

Re: [Django] #33954: "NaN" can be stored in DecimalField but cannot be retrieved

[Django]

#33954: "NaN" can be stored in DecimalField but cannot be retrieved
-+-
 Reporter:  Xabier Bello |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.1
  (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 Neeraj Kumar):

 I think **`from_float`** method will be enough for this.


 {{{
 def to_python(self, value):
 if value is None:
 return value
 if isinstance(value, float):
 if math.isnan(value):
 raise exceptions.ValidationError(
 self.error_messages['invalid'],
 code='invalid',
 params={'value': value},
 )
 return self.context.create_decimal_from_float(value)
 try:
 return decimal.Decimal.from_float(value) # If any value that
 is not floating or int, it will give TypeError, like 'nan' and 'inf' will
 be TypeError for this.
 except (decimal.InvalidOperation, TypeError, ValueError):
 raise exceptions.ValidationError(
 self.error_messages['invalid'],
 code='invalid',
 params={'value': value},
 )
 }}}

-- 
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/01070182d6549838-a9e857b0-9e65-4847-b88b-4a3bcb43ac29-00%40eu-central-1.amazonses.com.

Re: [Django] #24179: FilteredSelectMultiple widget - add filter field to the right column.

[Django]

#24179: FilteredSelectMultiple widget - add filter field to the right column.
-+-
 Reporter:  gdmka|Owner:  Gav
 |  O'Connor
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  FilteredSelectMultiple,|
  filter_horizontal, UI  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Gav O'Connor):

 * needs_better_patch:  1 => 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/01070182d6ad70e9-9dcdaa2b-6c76-458c-83c9-626fc95be0bb-00%40eu-central-1.amazonses.com.

[Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
   Reporter: |  Owner:  nobody
  semenfilippov  |
   Type:  Bug| Status:  new
  Component: |Version:  4.1
  Internationalization   |   Keywords:  timesince,
   Severity:  Normal |  datetime, localization,
   Triage Stage: |  internationalization
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Despite datetime objects being translated as expected, when using
 timesince filter with ru-RU locale, default (en) translation is rendered.
 However, this is not the case with other locales I tested (de, fr, ko).
 Also, this issue is not present in earlier Django versions (the one I
 tested is 2.2). I've checked .po file for ru-RU, it seems to have all
 translations 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/01070182d6b44150-2b46a670-2a0e-4d2c-a1c9-42e668a7df3b-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Semen Filippov):

 * Attachment "mre.zip" added.

 MRE project

-- 
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/01070182d6b6fd81-3b1e9c31-c8ea-42f2-a2fa-27e251a2e24e-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Semen Filippov:

Old description:

> Despite datetime objects being translated as expected, when using
> timesince filter with ru-RU locale, default (en) translation is rendered.
> However, this is not the case with other locales I tested (de, fr, ko).
> Also, this issue is not present in earlier Django versions (the one I
> tested is 2.2). I've checked .po file for ru-RU, it seems to have all
> translations required.

New description:

 Despite datetime objects being translated as expected, when using
 timesince filter with ru-RU locale, default (en) translation is rendered.
 However, this is not the case with other locales I tested (de, fr, ko).
 Also, this issue is not present in earlier Django versions (the one I
 tested is 2.2). I've checked .po file for ru-RU, it seems to have all
 translations required.
 
[https://github.com/django/django/commit/e4430f22c8e3d29ce5d9d0263fba57121938d06d
 This commit] seems to introduce this bug.

--

-- 
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/01070182d6e29e74-1d138753-0e40-4eb6-9544-18215ce7a8c9-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Semen Filippov:

Old description:

> Despite datetime objects being translated as expected, when using
> timesince filter with ru-RU locale, default (en) translation is rendered.
> However, this is not the case with other locales I tested (de, fr, ko).
> Also, this issue is not present in earlier Django versions (the one I
> tested is 2.2). I've checked .po file for ru-RU, it seems to have all
> translations required.
> [https://github.com/django/django/commit/e4430f22c8e3d29ce5d9d0263fba57121938d06d
> This commit] seems to introduce this bug.

New description:

 Despite datetime objects are translated as expected, when using timesince
 filter with ru-RU locale, default (en) translation is rendered. However,
 this is not the case with other locales I tested (de, fr, ko). Also, this
 issue is not present in earlier Django versions (the one I tested is 2.2).
 I've checked .po file for ru-RU, it seems to have all translations
 required.
 
[https://github.com/django/django/commit/e4430f22c8e3d29ce5d9d0263fba57121938d06d
 This commit] seems to introduce this bug.

--

-- 
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/01070182d6ef70d5-4fd742c9-c7e4-43cf-af0c-573d4d2f563f-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  timesince,   | Triage Stage:  Accepted
  datetime, localization,|
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Semen Filippov):

 * 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/01070182d6f00e73-7cf576b9-e995-4cda-b468-7e5695c03cd0-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Unreviewed


Comment:

 Please don't accept your own tickets.

-- 
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/01070182d845b69a-1603ac97-9ad3-40dd-8b36-f4e8861e4c7c-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
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 the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

 > I've checked .po file for ru-RU, it seems to have all translations
 required.

 We've changed the format to the `%(num)d`, so `ru` translation should be
 updated at Transifex.

-- 
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/01070182d84c7a7a-cac0a72b-e242-4240-b385-947cd6545d13-00%40eu-central-1.amazonses.com.

Re: [Django] #33953: RenameModel breaking change in 4.1 with ManyToManyField

[Django]

#33953: RenameModel breaking change in 4.1 with ManyToManyField
-+-
 Reporter:  Timothy Thomas   |Owner:  Iuri de
 |  Silvio
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  RenameModel  | 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):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182d85a191c-c19fae6a-0abc-418f-8df2-1dd623dc8e39-00%40eu-central-1.amazonses.com.

Re: [Django] #33201: RenameModel with db_table should be a noop.

[Django]

#33201: RenameModel with db_table should be a noop.
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   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:"166a3b32632c141541d1c3f0eff18e1d8b389404" 166a3b32]:
 {{{
 #!CommitTicketReference repository=""
 revision="166a3b32632c141541d1c3f0eff18e1d8b389404"
 Fixed #33953 -- Reverted "Fixed #33201 -- Made RenameModel operation a
 noop for models with db_table."

 Regression in afeafd6036616bac8263d762c1610f22241c0187.
 This reverts afeafd6036616bac8263d762c1610f22241c0187.

 Thanks Timothy Thomas for the report.
 }}}

-- 
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/01070182d8931bf3-23eb9deb-2fb3-4830-a78b-ee7e2af8f736-00%40eu-central-1.amazonses.com.

Re: [Django] #33953: RenameModel breaking change in 4.1 with ManyToManyField

[Django]

#33953: RenameModel breaking change in 4.1 with ManyToManyField
-+-
 Reporter:  Timothy Thomas   |Owner:  Iuri de
 |  Silvio
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  RenameModel  | 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:"166a3b32632c141541d1c3f0eff18e1d8b389404" 166a3b32]:
 {{{
 #!CommitTicketReference repository=""
 revision="166a3b32632c141541d1c3f0eff18e1d8b389404"
 Fixed #33953 -- Reverted "Fixed #33201 -- Made RenameModel operation a
 noop for models with db_table."

 Regression in afeafd6036616bac8263d762c1610f22241c0187.
 This reverts afeafd6036616bac8263d762c1610f22241c0187.

 Thanks Timothy Thomas for the report.
 }}}

-- 
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/01070182d8931bf4-43b7fac7-4e12-4f93-b023-de1f9739d424-00%40eu-central-1.amazonses.com.

Re: [Django] #33201: RenameModel with db_table should be a noop.

[Django]

#33201: RenameModel with db_table should be a noop.
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   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:"7d5ccbbe1a3ad99b02c25f1ce90f36334d881ab6" 7d5ccbbe]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d5ccbbe1a3ad99b02c25f1ce90f36334d881ab6"
 [4.1.x] Fixed #33953 -- Reverted "Fixed #33201 -- Made RenameModel
 operation a noop for models with db_table."

 Regression in afeafd6036616bac8263d762c1610f22241c0187.
 This reverts afeafd6036616bac8263d762c1610f22241c0187.

 Thanks Timothy Thomas for the report.

 Backport of 166a3b32632c141541d1c3f0eff18e1d8b389404 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/01070182d89379b9-aa8ca1ee-30f4-4139-8e4e-a5f4ff2b52b2-00%40eu-central-1.amazonses.com.

Re: [Django] #33953: RenameModel breaking change in 4.1 with ManyToManyField

[Django]

#33953: RenameModel breaking change in 4.1 with ManyToManyField
-+-
 Reporter:  Timothy Thomas   |Owner:  Iuri de
 |  Silvio
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  RenameModel  | 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:"7d5ccbbe1a3ad99b02c25f1ce90f36334d881ab6" 7d5ccbbe]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d5ccbbe1a3ad99b02c25f1ce90f36334d881ab6"
 [4.1.x] Fixed #33953 -- Reverted "Fixed #33201 -- Made RenameModel
 operation a noop for models with db_table."

 Regression in afeafd6036616bac8263d762c1610f22241c0187.
 This reverts afeafd6036616bac8263d762c1610f22241c0187.

 Thanks Timothy Thomas for the report.

 Backport of 166a3b32632c141541d1c3f0eff18e1d8b389404 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/01070182d893799e-6903e60c-e595-4260-bcdb-d5b7f10c4fa3-00%40eu-central-1.amazonses.com.

Re: [Django] #33201: RenameModel with db_table should be a noop.

[Django]

#33201: RenameModel with db_table should be a noop.
-+-
 Reporter:  Iuri de Silvio   |Owner:  Iuri de
 Type:   |  Silvio
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  1 => 0
 * resolution:  fixed => wontfix
 * stage:  Ready for checkin => Unreviewed


-- 
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/01070182d8961135-1f99a5ea-25e4-4f98-b0be-3d68ae3d9105-00%40eu-central-1.amazonses.com.

Re: [Django] #33956: timesince filter localization doesn't work for ru-RU

[Django]

#33956: timesince filter localization doesn't work for ru-RU
-+-
 Reporter:  Semen Filippov   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  timesince,   | Triage Stage:
  datetime, localization,|  Unreviewed
  internationalization   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Semen Filippov):

 Replying to [comment:4 Mariusz Felisiak]:
 > Please don't accept your own tickets.
 Yeah, I apologize, this is actually my first reported issue ever.
 Should’ve guessed this is wrong.

-- 
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/01070182d8d6d56d-89c6707a-7ef5-4526-8816-d3e73b165d9c-00%40eu-central-1.amazonses.com.