Re: [Django] #28900: QuerySet.values() and values_list() for compound queries fails with annotation.

[Django]

#28900: QuerySet.values() and values_list() for compound queries fails with
annotation.
-+-
 Reporter:  elliott-omosheye |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union, values| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * cc: Sergey Fedoseev (removed)


-- 
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/0107018af3f806f1-e3277f45-8746-427a-b515-c0ad06885ee8-00%40eu-central-1.amazonses.com.

Re: [Django] #34884: Half bug/half enhancement : inconsistent behavior of get_or_create() regarding related attributes cache

[Django]

#34884: Half bug/half enhancement : inconsistent behavior of get_or_create()
regarding related attributes cache
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM get_or_create| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Hi Laurent,

 To echo what Natalian said, please avoid comments like "in case some
 bikeshedding occurs that puts to trash coherency and efficiency in yet
 another open source software where some people against free software have
 influence". It adds nothing helpful. Assuming bad faith on the part of the
 Django community is no way to introduce yourself and get people to want to
 work with you. Thank you.

 As for the issue, I think it's a bit of a niche case. I mocked up a patch
 using your proposal. I'm not sure that the extra complexity is worthwhile,
 as well as the performance penalty of iterating through the `kwargs`
 (which is unnecessary when a foreign key isn't present). The patch may
 need consideration for other relations like `GenericForeignKey`. I'm not
 sure offhand. I wonder if `update_or_create()` has a similar
 inconsistency. I'm afraid that trying to make the ORM smarter about this
 might open a can of worms.

 Cheers!

 {{{ #!diff
 diff --git a/django/db/models/query.py b/django/db/models/query.py
 index 1125302933..818d31faac 100644
 --- a/django/db/models/query.py
 +++ b/django/db/models/query.py
 @@ -939,11 +939,20 @@ class QuerySet(AltersData):
  Return a tuple of (object, created), where created is a boolean
  specifying whether an object was created.
  """
 +from django.db.models.fields.related import ForeignKey
  # The get() needs to be targeted at the write database in order
  # to avoid potential transaction consistency problems.
  self._for_write = True
  try:
 -return self.get(**kwargs), False
 +obj, created = self.get(**kwargs), False
 +for key, value in kwargs.items():
 +try:
 +if isinstance(obj._meta.get_field(key), ForeignKey):
 +# isinstance handles OneToOneField also.
 +setattr(obj, key, value)
 +except exceptions.FieldDoesNotExist:
 +pass
 +return obj, created
  except self.model.DoesNotExist:
  params = self._extract_model_params(defaults, **kwargs)
  # Try to create an object using passed params.
 @@ -953,6 +962,7 @@ class QuerySet(AltersData):
  return self.create(**params), True
  except IntegrityError:
  try:
 +# Another get() case that would need to be updated.
  return self.get(**kwargs), False
  except self.model.DoesNotExist:
  pass
 diff --git a/tests/get_or_create/tests.py b/tests/get_or_create/tests.py
 index 0b56d6b1a2..4aac3ff580 100644
 --- a/tests/get_or_create/tests.py
 +++ b/tests/get_or_create/tests.py
 @@ -129,8 +129,19 @@ class GetOrCreateTests(TestCase):
  self.assertEqual(book.authors.count(), 2)

  # Try creating a book through an author.
 -_, created = ed.books.get_or_create(name="Ed's Recipes",
 publisher=p)
 +eds_recipes, created = ed.books.get_or_create(name="Ed's
 Recipes", publisher=p)
  self.assertTrue(created)
 +# In the created=True case, the publisher is set on the new
 object.
 +with self.assertNumQueries(0):
 +self.assertEqual(eds_recipes.publisher.name, 'Acme
 Publishing')
 +
 +# In the case of created=False, the publisher isn't set on the
 object.
 +eds_recipes, created = ed.books.get_or_create(name="Ed's
 Recipes", publisher=p)
 +self.assertFalse(created)
 +# This assertion fails due to the query required to fetch the
 +# publisher, demonstrating #34884.
 +with self.assertNumQueries(0):
 +self.assertEqual(eds_recipes.publisher.name, 'Acme
 Publishing')

  # Now Ed has two Books, Fred just one.
  self.assertEqual(ed.books.count(), 2)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists 

Re: [Django] #34884: Half bug/half enhancement : inconsistent behavior of get_or_create() regarding related attributes cache

[Django]

#34884: Half bug/half enhancement : inconsistent behavior of get_or_create()
regarding related attributes cache
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM get_or_create| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Natalia Bidart):

 Laurent, first of all, please maintain a professional tone and adhere to
 the [https://www.djangoproject.com/conduct/ Django Code of Conduct] when
 composing/sending messages.

 Secondly, if you disagree with this resolution, you are welcomed to follow
 [https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-
 features/#requesting-features the documentation] and start a new
 conversation on the [https://forum.djangoproject.com/c/internals/5 Django
 Forum], where you'll reach a wider audience and likely get more feedback.

-- 
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/0107018af314ab2d-90078bf3-1a46-4a09-b2e9-1ca0bfedb337-00%40eu-central-1.amazonses.com.

Re: [Django] #34884: Half bug/half enhancement : inconsistent behavior of get_or_create() regarding related attributes cache

[Django]

#34884: Half bug/half enhancement : inconsistent behavior of get_or_create()
regarding related attributes cache
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM get_or_create| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Laurent Lyaudet):

 Hello Natalia,

 Your solution is suboptimal to say the least and denotes a lack of thought
 on what happens under the hood.
 I was somehow prepared for such an answer that proves that BS reigns
 suprems in most FOSS.

 Here are the problems :
 - First: adding a select_related is as cumbersome to write than the line:
 {{{
 my_object.related_object = related_object
 }}}
 in my first ticket description :
 {{{
 my_object = MyModel.objects.get_or_create(related_object=related_object)
 my_object.related_object = related_object
 }}}

 - Second: adding a select_related is worse than the line above when it
 comes to the extra computation that you add both in Python and in the
 DBMS.
 This join is useless, it is superfluous work for the machine, bad
 programming.

 - Third and most important: for the consistency of your data, with
 select_related you now have 2 objects of type ContentType.
 If you update one of these 2 objects in Python, the other is not updated
 unless, you save the first and refresh from db the second.
 This is plain bad programming.

 - Fourth: setting arrogantly * status:  new => closed * resolution:   =>
 invalid is a full proof of how BS this kind of answer is.


 Replying to [comment:3 Natalia Bidart]:
 > Hello Laurent, thank you for your ticket.
 >
 > As far as I understand your report, the key to your issue is about using
 `select_related` when getting the `Permission` you need. Specifically, see
 how if I create a permission using the content_type's PK, the resulting
 object does not have the ContentType instance fetched by default:
 >
 > {{{#!python
 > >>> permission, created = Permission.objects.get_or_create(name="Test",
 content_type_id=content_type.pk, codename="OtherTest")
 > >>> print("\n\n".join(i["sql"] for i in connection.queries))
 > SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename" FROM
 "auth_permission" WHERE ("auth_permission"."codename" = 'OtherTest' AND
 "auth_permission"."content_type_id" = 2 AND "auth_permission"."name" =
 'Test') LIMIT 21
 >
 > BEGIN
 >
 > INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
 VALUES ('Test', 2, 'OtherTest') RETURNING "auth_permission"."id"
 >
 > COMMIT
 >
 > >>> permission.content_type
 > 
 > >>> print("\n\n".join(i["sql"] for i in connection.queries))
 > SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename" FROM
 "auth_permission" WHERE ("auth_permission"."codename" = 'OtherTest' AND
 "auth_permission"."content_type_id" = 2 AND "auth_permission"."name" =
 'Test') LIMIT 21
 >
 > BEGIN
 >
 > INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
 VALUES ('Test', 2, 'OtherTest') RETURNING "auth_permission"."id"
 >
 > COMMIT
 >
 > SELECT "django_content_type"."id", "django_content_type"."app_label",
 "django_content_type"."model" FROM "django_content_type" WHERE
 "django_content_type"."id" = 2 LIMIT 21
 > }}}
 >
 > You can see the extra query at the end when the `content_type` attribute
 is accessed. Similarly, you can avoid the "extra" query when the object
 exists by doing:
 >
 > {{{#!python
 > >>> permission, created =
 Permission.objects.select_related("content_type").get_or_create(name="Test",
 content_type_id=content_type.pk, codename="OtherTest")
 > >>> print("\n\n".join(i["sql"] for i in connection.queries))
 > SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename",
 "django_content_type"."id", "django_content_type"."app_label",
 "django_content_type"."model" FROM "auth_permission" INNER JOIN
 "django_content_type" ON ("auth_permission"."content_type_id" =
 "django_content_type"."id") WHERE ("auth_permission"."codename" =
 'OtherTest' AND "auth_permission"."content_type_id" = 2 AND
 "auth_permission"."name" = 'Test') LIMIT 21
 >
 > >>> permission.content_type
 > 
 > >>> print("\n\n".join(i["sql"] for i in connection.queries))
 > SELECT "auth_permission"."id", 

Re: [Django] #27229: Allow using aggregates in ModelAdmin.list_display

[Django]

#27229: Allow using aggregates in ModelAdmin.list_display
---+
 Reporter:  Dor|Owner:  Dor
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Olivier Dalang):

 * cc: Olivier Dalang (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/0107018af24e08fa-314fbd32-c3b0-4607-9e30-3593ca741be2-00%40eu-central-1.amazonses.com.

Re: [Django] #14336: list_display should be able to contain sortable references to annotated fields

[Django]

#14336: list_display should be able to contain sortable references to annotated
fields
+
 Reporter:  Paul McLanahan  |Owner:  (none)
 Type:  New feature |   Status:  new
Component:  contrib.admin   |  Version:  1.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Olivier Dalang):

 * cc: Olivier Dalang (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/0107018af24db650-8f6ab132-071e-4197-880d-5e9d79ee7b4f-00%40eu-central-1.amazonses.com.

Re: [Django] #34884: Half bug/half enhancement : inconsistent behavior of get_or_create() regarding related attributes cache

[Django]

#34884: Half bug/half enhancement : inconsistent behavior of get_or_create()
regarding related attributes cache
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM get_or_create| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

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


Comment:

 Hello Laurent, thank you for your ticket.

 As far as I understand your report, the key to your issue is about using
 `select_related` when getting the `Permission` you need. Specifically, see
 how if I create a permission using the content_type's PK, the resulting
 object does not have the ContentType instance fetched by default:

 {{{#!python
 >>> permission, created = Permission.objects.get_or_create(name="Test",
 content_type_id=content_type.pk, codename="OtherTest")
 >>> print("\n\n".join(i["sql"] for i in connection.queries))
 SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename" FROM
 "auth_permission" WHERE ("auth_permission"."codename" = 'OtherTest' AND
 "auth_permission"."content_type_id" = 2 AND "auth_permission"."name" =
 'Test') LIMIT 21

 BEGIN

 INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
 VALUES ('Test', 2, 'OtherTest') RETURNING "auth_permission"."id"

 COMMIT

 >>> permission.content_type
 
 >>> print("\n\n".join(i["sql"] for i in connection.queries))
 SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename" FROM
 "auth_permission" WHERE ("auth_permission"."codename" = 'OtherTest' AND
 "auth_permission"."content_type_id" = 2 AND "auth_permission"."name" =
 'Test') LIMIT 21

 BEGIN

 INSERT INTO "auth_permission" ("name", "content_type_id", "codename")
 VALUES ('Test', 2, 'OtherTest') RETURNING "auth_permission"."id"

 COMMIT

 SELECT "django_content_type"."id", "django_content_type"."app_label",
 "django_content_type"."model" FROM "django_content_type" WHERE
 "django_content_type"."id" = 2 LIMIT 21
 }}}

 You can see the extra query at the end when the `content_type` attribute
 is accessed. Similarly, you can avoid the "extra" query when the object
 exists by doing:

 {{{#!python
 >>> permission, created =
 Permission.objects.select_related("content_type").get_or_create(name="Test",
 content_type_id=content_type.pk, codename="OtherTest")
 >>> print("\n\n".join(i["sql"] for i in connection.queries))
 SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename",
 "django_content_type"."id", "django_content_type"."app_label",
 "django_content_type"."model" FROM "auth_permission" INNER JOIN
 "django_content_type" ON ("auth_permission"."content_type_id" =
 "django_content_type"."id") WHERE ("auth_permission"."codename" =
 'OtherTest' AND "auth_permission"."content_type_id" = 2 AND
 "auth_permission"."name" = 'Test') LIMIT 21

 >>> permission.content_type
 
 >>> print("\n\n".join(i["sql"] for i in connection.queries))
 SELECT "auth_permission"."id", "auth_permission"."name",
 "auth_permission"."content_type_id", "auth_permission"."codename",
 "django_content_type"."id", "django_content_type"."app_label",
 "django_content_type"."model" FROM "auth_permission" INNER JOIN
 "django_content_type" ON ("auth_permission"."content_type_id" =
 "django_content_type"."id") WHERE ("auth_permission"."codename" =
 'OtherTest' AND "auth_permission"."content_type_id" = 2 AND
 "auth_permission"."name" = 'Test') LIMIT 21
 }}}

-- 
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/0107018af1d2e4c7-59ec2fea-8d35-4f5c-a208-e36b2f4f2ce2-00%40eu-central-1.amazonses.com.

Re: [Django] #34118: Python 3.12 compatibility

[Django]

#34118: Python 3.12 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * status:  new => assigned
 * stage:  Someday/Maybe => Accepted


Comment:

 https://www.python.org/downloads/release/python-3120/

-- 
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/0107018af1bc7ad5-6668cc28-62a4-4e08-ba32-d172259882b5-00%40eu-central-1.amazonses.com.

Re: [Django] #12090: Show admin actions on the edit pages too

[Django]

#12090: Show admin actions on the edit pages too
-+-
 Reporter:  Florian Apolloner|Owner:  Marcelo
 |  Galigniana
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marcelo Galigniana):

 * needs_better_patch:  1 => 0


Comment:

 Tests passing

-- 
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/0107018af1a827c1-762457c9-811b-4cd9-a82e-b5b43faf9886-00%40eu-central-1.amazonses.com.

Re: [Django] #34865: DatabaseWrapper are not GC and connections are not closed

[Django]

#34865: DatabaseWrapper are not GC and connections are not closed
-+-
 Reporter:  Fábio Domingues  |Owner:  Priyank
 |  Panchal
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Priyank Panchal):

 * owner:  nobody => Priyank Panchal
 * 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/0107018af1a7a1e8-63df2ad0-be1a-4b4d-8779-430a3dc7fcf4-00%40eu-central-1.amazonses.com.

Re: [Django] #12090: Show admin actions on the edit pages too

[Django]

#12090: Show admin actions on the edit pages too
-+-
 Reporter:  Florian Apolloner|Owner:  Marcelo
 |  Galigniana
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marcelo Galigniana):

 * needs_better_patch:  0 => 1


Comment:

 Test failing!

 Working on fix.

-- 
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/0107018af0e7e1d6-0e95f09a-9ac4-4dc5-9f85-0376f657c099-00%40eu-central-1.amazonses.com.

Re: [Django] #34883: Allow template tags to set extra data on templates.

[Django]

#34883: Allow template tags to set extra data on templates.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  5.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"35bbb2c9c01882b1d77b0b8c737ac646144833d4" 35bbb2c]:
 {{{
 #!CommitTicketReference repository=""
 revision="35bbb2c9c01882b1d77b0b8c737ac646144833d4"
 Fixed #34883 -- Allowed template tags to set extra data on templates.

 By setting a value in the `parser.extra_data` mapping, template tags
 pass additional data out of the parsing context.

 Any extra data set is exposed on the template via the matching
 `.extra_data` attribute.

 Library authors should use a key to namespace extra data. The 'django'
 namespace is reserved for internal use.
 }}}

-- 
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/0107018af0dc1070-4f84fd52-9de4-4876-aa93-0a36eff386e3-00%40eu-central-1.amazonses.com.

Re: [Django] #34883: Allow template tags to set extra data on templates.

[Django]

#34883: Allow template tags to set extra data on templates.
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 |  Gibson
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018af09bd841-9ed9608b-66a1-4259-8f1d-ba0b49c05fa4-00%40eu-central-1.amazonses.com.

Re: [Django] #34853: Accept-Language Header takes precedence over cookie for format localization

[Django]

#34853: Accept-Language Header takes precedence over cookie for format 
localization
-+-
 Reporter:  blue-hexagon |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  dev
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  l10n format  | Triage Stage:
  localization   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Natalia Bidart):

 * stage:  Accepted => 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/0107018af08019e9-3a0fd620-078a-4b44-997d-467748529a3b-00%40eu-central-1.amazonses.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  Faishal
 Type:   |  Manzar
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"25a614639fe524aa1e9a97b1aee32c54a8fe310e" 25a61463]:
 {{{
 #!CommitTicketReference repository=""
 revision="25a614639fe524aa1e9a97b1aee32c54a8fe310e"
 [5.0.x] Fixed #32602 -- Clarified wording of TestCase class.

 Backport of f4e72e6523e6968d9628dfbff914ab57dbf19e6b 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/0107018aefcb0838-db6ae1f4-85de-477e-ae8f-63fc433c6553-00%40eu-central-1.amazonses.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  Faishal
 Type:   |  Manzar
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 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:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"f4e72e6523e6968d9628dfbff914ab57dbf19e6b" f4e72e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="f4e72e6523e6968d9628dfbff914ab57dbf19e6b"
 Fixed #32602 -- Clarified wording of TestCase class.
 }}}

-- 
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/0107018aefca5a20-0b7a3b35-7d51-4c49-bf9b-8e41411d2aaf-00%40eu-central-1.amazonses.com.

Re: [Django] #34886: Sample use of lazy in delayed translations is not valid in Django 4.1 and 4.2. (was: Docs: Sample use of lazy in delayed translations is not valid anymore)

[Django]

#34886: Sample use of lazy in delayed translations is not valid in Django 4.1 
and
4.2.
---+
 Reporter:  Stefan Hammer  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  4.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 It was fixed in Django 5.0 (check out
 066aabcb77579cf8d549119c860d11cd15e3eef1). Would you like to prepare a
 patch? (targeted to the `stable/4.2.x`).

-- 
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/0107018aef6def24-b48c813e-f88d-42b0-8ff3-b48fa9f49a33-00%40eu-central-1.amazonses.com.

Re: [Django] #34759: Confirm/Add support for SpatiaLite 5.1

[Django]

#34759: Confirm/Add support for SpatiaLite 5.1
-+-
 Reporter:  Olivier Tabone   |Owner:  Pieter
 Type:   |  Cardillo Kwok
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Pieter Cardillo Kwok):

 Hello guys I was able to replicate the error by updating spatialite to
 5.1.0 and using django docker box. So I'd like to take ownership of the
 ticket and start debugging the error. I'll provide some updates
 periodically here and I'm also active in Django discord forum. Please feel
 free to reach out through discord if needed (my discord name: @peter. tag:
 ,# 5816 ).

-- 
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/0107018aef44acbe-800ada18-1396-405c-ac73-b748482b34b9-00%40eu-central-1.amazonses.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  Faishal
 Type:   |  Manzar
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/0107018aef3c0479-fce70876-2631-40dd-b378-42fd4be8fe08-00%40eu-central-1.amazonses.com.

Re: [Django] #34759: Confirm/Add support for SpatiaLite 5.1

[Django]

#34759: Confirm/Add support for SpatiaLite 5.1
-+-
 Reporter:  Olivier Tabone   |Owner:  Pieter
 Type:   |  Cardillo Kwok
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Pieter Cardillo Kwok):

 * owner:  Aman Gora => Pieter Cardillo Kwok


-- 
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/0107018aef3428a0-978b9e43-aa7c-49c1-a9e0-db5e15d5db0d-00%40eu-central-1.amazonses.com.

[Django] #34886: Docs: Sample use of lazy in delayed translations is not valid anymore

[Django]

#34886: Docs: Sample use of lazy in delayed translations is not valid anymore
-+
   Reporter:  Stefan Hammer  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  4.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 The sample code to mark a lazy translation as "safe" in the docs
 [https://docs.djangoproject.com/en/dev/topics/i18n/translation/#other-
 uses-of-lazy-in-delayed-translations here] seems to be invalid since
 Django 4.1 (#20296).

 We're in the process of upgrading a Django 3.2 installation to Django 4.2
 and we've used this utility `mark_safe_lazy` from the sample in our code.
 This code now produces the error `__str__ returned non-string (type
 __proxy__)` when rendering such a value in the templates.

 The fix seems to simply use Django's `mark_safe(gettext_lazy(...))`
 instead of this custom helper.

-- 
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/0107018aef0a8ec9-ea944377-f60f-46de-9b37-d15c0efef107-00%40eu-central-1.amazonses.com.