Re: [Django] #33973: Performance regression when moving from 3.1 to 3.2

[Django]

#33973: Performance regression when moving from 3.1 to 3.2
-+-
 Reporter:  Marc Parizeau|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  performance  | Triage Stage:
  regression |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Bonjour Marc,

 There are some sources listed on the
 [https://github.com/django/django/pull/13606 PR]  that introduced these
 changes that documents the performance benefits of using `EXISTS` over
 `IN` and the case where `IN` will be faster which I believe is what you're
 experiencing here.

 Given there are performance benefits in most cases and `IN` is only faster
 [https://www.percona.com/blog/2020/04/16/sql-optimizations-in-postgresql-
 in-vs-exists-vs-any-all-vs-join/ when the subquery returns a small number
 of rows] as a hashmap can be created I believe we should keep the change
 around.

 The good news is that you can restore the previous behaviour by being more
 explicit in your usage of `exclude` by using an explicit `IN` lookup
 instead.

 {{{#!python
 user_thread_entries = ThreadEntry.objects.filter(user=user,
 thread__isnull=False).values("thread")
 Content.objects.annotate(
 unread=Exists(
 Thread.objects.filter(
 content=OuterRef('pk'),
 ).exclude(pk__in=user_thread_entries)
 )
 ).filter(
 unread=True,
 )
 }}}

 Keep in mind though that, as pointed out in the article, this query will
 only be faster for users with a relatively small number of thread entries
 as Postgres will turn the set of rows into a hashmap which is means that
 this query will become more expensive as the number of threads user
 creates increase.

-- 
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/0107018300ca64f2-0224d45b-3d9a-49bd-826c-d4ed86803f1a-00%40eu-central-1.amazonses.com.

Re: [Django] #33975: __in doesn't clear selected fields on the RHS when QuerySet.alias() is used after annotate().

[Django]

#33975: __in doesn't clear selected fields on the RHS when QuerySet.alias() is 
used
after annotate().
-+-
 Reporter:  Gabriel Muj  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Whether or not the `In` lookups defaults a `Query` right-hand-side to
 `.values('pk')` is based of `rhs.has_select_fields`
 
([https://github.com/django/django/blob/cd1afd553f9c175ebccfc0f50e72b43b9604bd97/django/db/models/lookups.py#L421-L425
 source])

 This dynamic property is based of `self.select or
 self.annotation_select_mask` so I suspect that there might be some bad
 logic in `Query.add_annotation`
 
([https://github.com/django/django/blob/b3db6c8dcb5145f7d45eff517bcd96460475c879/django/db/models/sql/query.py#L1109-L1119
 source]) from the introduction of `QuerySet.alias` in
 f4ac167119e8897c398527c392ed117326496652.

 The
 `self.set_annotation_mask(set(self.annotation_select).difference({alias}))`
 
[https://github.com/django/django/commit/f4ac167119e8897c398527c392ed117326496652
 #diff-
 fd2300283d1546e36141373b0621f142ed871e3e8856e07efe5a22ecc38ad620R1025
 line] seems to be what causes the problem here. If `annotate` and `alias`
 are used then `annotation_select_mask` will be materialized as a ''mask''
 is required to keep track of which entries in `annotations` must be
 selected and whatnot (not necessary if only using `alias` or `annotate` as
 the first doesn't require any selecting and the second selects all
 annotations)

 The `add_annotation` logic relied on to implement `QuerySet.alias` is not
 wrong per se it just happens to piggy back on the annotation masking logic
 that only `Query.set_values` relied on previously an now happens to break
 the heuristics in `Query.has_select_fields`.

 The proper solutions is likely to replace `Query.has_select_fields` by a
 class attribute that defaults to `False` and have `set_values` set it to
 `True` and make sure `Query.clone` carries the attribute over. This seems
 like a more durable options as that avoids trying to peek into internals
 to determine if a `values` call was performed.

-- 
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/0107018300ae8c8e-399e8bdc-ceaa-49b8-8638-5bc8ae44b337-00%40eu-central-1.amazonses.com.

Re: [Django] #33662: Choose which items are displayed per language in Sitemap (was: Choose witch items are to be display per language in Sitemap)

[Django]

#33662: Choose which items are displayed per language in Sitemap
--+
 Reporter:  roxanebellot  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sitemaps  |  Version:  4.0
 Severity:  Normal|   Resolution:
 Keywords:  sitemap   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * component:  Uncategorized => contrib.sitemaps


-- 
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/01070183002f150e-d1223f52-61ad-4cea-a70b-8ef1c95e49f1-00%40eu-central-1.amazonses.com.

Re: [Django] #33978: django.contrib.humanize - Portuguese translations for naturaltime seem broken

[Django]

#33978: django.contrib.humanize - Portuguese translations for naturaltime seem
broken
-+-
 Reporter:  zepires  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  4.0
  Internationalization   |
 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
-+-
Changes (by Claude Paroz):

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


Comment:

 Indeed, Portuguese translations for `contrib.humanize` are incomplete.
 Thanks for the report, however this should be handled by translators on
 Transifex. Translation issues are not handled in this tracker.

-- 
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/01070182ffbef51d-8afe5a0d-58d6-4888-bb12-71afa1236791-00%40eu-central-1.amazonses.com.

[Django] #33978: django.contrib.humanize - Portuguese translations for naturaltime seem broken

[Django]

#33978: django.contrib.humanize - Portuguese translations for naturaltime seem
broken
+
   Reporter:  zepires   |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Internationalization  |Version:  4.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 |
+
 When trying to use the European Portuguese (pt) version of 'naturaltime'
 method, it falls back to English.

 With other languages (French, Italian, Spanish, Greek, German) I don't see
 the same effect - timespans are translated correctly.

-- 
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/01070182fe8d93d3-c4258d95-853b-44e7-bd6d-d95f51e7b5ab-00%40eu-central-1.amazonses.com.

Re: [Django] #29799: Allow registration and unregistration of lookups per field instances.

[Django]

#29799: Allow registration and unregistration of lookups per field instances.
-+-
 Reporter:  Simon Charette   |Owner:
 |  AllenJonathan
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  GSoC | 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:

 See
 
https://github.com/django/django/commit/cd1afd553f9c175ebccfc0f50e72b43b9604bd97.

-- 
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/01070182fdca6f37-6a70ceee-11c8-41ee-bbfe-dc7a4280c54d-00%40eu-central-1.amazonses.com.

Re: [Django] #33977: Grouping action in the ModelAdmin

[Django]

#33977: Grouping action in the ModelAdmin
--+--
 Reporter:  Willem Van Onsem  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.admin |  Version:  dev
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #33807.

-- 
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/01070182fdc71326-d517156f-c75c-4f42-9d11-bf49c9f4eaa6-00%40eu-central-1.amazonses.com.

Re: [Django] #33977: Grouping action in the ModelAdmin

[Django]

#33977: Grouping action in the ModelAdmin
--+--
 Reporter:  Willem Van Onsem  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.admin |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Willem Van Onsem):

 * Attachment "django-actions.patch" 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/01070182fdbfad74-ce2b0eb3-376e-42e3-ab2d-c9d754ab85bf-00%40eu-central-1.amazonses.com.

[Django] #33977: Grouping action in the ModelAdmin

[Django]

#33977: Grouping action in the ModelAdmin
+
   Reporter:  Willem Van Onsem  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.admin |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 One can make the action dropdown visually more pleasant by introducing
 groups. This does not require a lot of logic: we can easily update the
 `@action` decorator to allow specifying an `action_group`, and by slightly
 modifying the `get_action_choices` method, we can generate a list of
 groups that contain the actions:

 {{{
 diff --git a/django/contrib/admin/decorators.py
 b/django/contrib/admin/decorators.py
 index d3ff56a59a..ad34df2e65 100644
 --- a/django/contrib/admin/decorators.py
 +++ b/django/contrib/admin/decorators.py
 @@ -1,4 +1,4 @@
 -def action(function=None, *, permissions=None, description=None):
 +def action(function=None, *, permissions=None, description=None,
 group=None):
  """
  Conveniently add attributes to an action function::

 @@ -23,6 +23,8 @@ def action(function=None, *, permissions=None,
 description=None):
  func.allowed_permissions = permissions
  if description is not None:
  func.short_description = description
 +if group is not None:
 +func.action_group = group
  return func

  if function is None:
 diff --git a/django/contrib/admin/options.py
 b/django/contrib/admin/options.py
 index 8ccacd6213..ca61901fe7 100644
 --- a/django/contrib/admin/options.py
 +++ b/django/contrib/admin/options.py
 @@ -1,4 +1,5 @@
  import copy
 +from collections import defaultdict
  import json
  import re
  from functools import partial, update_wrapper
 @@ -1024,11 +1025,13 @@ class ModelAdmin(BaseModelAdmin):
  Return a list of choices for use in a form object.  Each choice
 is a
  tuple (name, description).
  """
 +choices = defaultdict(list)
 +choices[None].extend(default_choices)
  choices = [] + default_choices
  for func, name, description in
 self.get_actions(request).values():
  choice = (name, description % model_format_dict(self.opts))
 -choices.append(choice)
 -return choices
 +choices[getattr(func, 'action_group', None)].append(choice)
 +return list(choices.items())

  def get_action(self, action):
  """
 }}}

-- 
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/01070182fdbf0bd6-3fb74845-8174-46bc-bf48-88ca35fd50c1-00%40eu-central-1.amazonses.com.

Re: [Django] #33976: HTTP_HOST does not allow an ipv6 not enclosed in []

[Django]

#33976: HTTP_HOST does not allow an ipv6 not enclosed in []
-+--
 Reporter:  eburghar |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ipv6 | 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):

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


Comment:

 As far as I'm aware, brackets are mandatory in the URI scheme for IPv6,
 see [https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2 RFC3986]:

 {{{
   IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
 }}}

-- 
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/01070182fda92fe9-436e9b1c-4a5f-4331-bfdf-1e4ca3f4dd92-00%40eu-central-1.amazonses.com.

Re: [Django] #33975: __in doesn't clear selected fields on the RHS when QuerySet.alias() is used after annotate(). (was: Using .filter with lookup field__in=queryset where queryset contains .annotate

[Django]

#33975: __in doesn't clear selected fields on the RHS when QuerySet.alias() is 
used
after annotate().
-+-
 Reporter:  Gabriel Muj  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  4.0
  (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
 * cc: Simon Charette, Alexandr Tatarinov (added)
 * resolution:  invalid =>
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Replying to [comment:3 Gabriel Muj]:
 > Using either {{{.alias}}} or {{{.annotate}}} works as expected without
 using {{{.values}}} to limit to 1 column. Why is that? but using both of
 them doesn't seem work.

 We have some simplification in the `__in` lookup that automatically limit
 selected fields to the `pk` when `Query` is on the right-side and the
 selected fields are undefined. It looks like they don't play nice when
 `.annotate()` and `.alias()` are mixed. Tentatively accepted for the
 investigation.

-- 
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/01070182fd976be3-59ecd0fd-fb60-47de-ad1a-cdc8e6dd7459-00%40eu-central-1.amazonses.com.

Re: [Django] #33976: HTTP_HOST does not allow an ipv6 not enclosed in []

[Django]

#33976: HTTP_HOST does not allow an ipv6 not enclosed in []
-+--
 Reporter:  eburghar |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  ipv6 | 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 eburghar:

Old description:

> Hi,
>
> If I'm not mistaken, brackets are optional for an ipv6 address without
> port number. The problem is that it confuses django. In `asgi.py` we have
>
> {{{
> Invalid HTTP_HOST header: '2001:x:y:z:0:0:0:1'. The domain name provided
> is not valid according to RFC 1034/1035.
> }}}
>
> which can be fixed by changing `django.http.request.host_validation_re`
> to `_lazy_re_compile(r"[a-zA-z0-9.:]*")`
>
> but it also triggers an exception with `asgi.py`
>
> {{{
> 2022/09/02 07:57:10 [alert] 422#422 [unit] Python failed to call
> 'loop.call_soon'
> Traceback (most recent call last):
>   File "/usr/lib/python3.10/asyncio/base_events.py", line 750, in
> call_soon
> self._check_closed()
> ValueError: invalid literal for int() with base 10: 'x:y:z:0:0:0:1'
> 2022/09/02 07:57:25 [alert] 422#422 [unit] #23: Python failed to create
> 'client' pair
> }}}

New description:

 Hi,

 If I'm not mistaken, brackets are optional for an ipv6 address without
 port number. The problem is that it confuses django.

 {{{
 Invalid HTTP_HOST header: '2001:x:y:z:0:0:0:1'. The domain name provided
 is not valid according to RFC 1034/1035.
 }}}

 which can be fixed by changing `django.http.request.host_validation_re` to
 `_lazy_re_compile(r"[a-zA-z0-9.:]*")`

 but it also triggers an exception with `asgi.py`

 {{{
 2022/09/02 07:57:10 [alert] 422#422 [unit] Python failed to call
 'loop.call_soon'
 Traceback (most recent call last):
   File "/usr/lib/python3.10/asyncio/base_events.py", line 750, in
 call_soon
 self._check_closed()
 ValueError: invalid literal for int() with base 10: 'x:y:z:0:0:0:1'
 2022/09/02 07:57:25 [alert] 422#422 [unit] #23: Python failed to create
 'client' pair
 }}}

--

-- 
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/01070182fd80cb27-928ba655-b851-4736-823f-05538324ccc2-00%40eu-central-1.amazonses.com.

Re: [Django] #33974: Serializer incorrectly serializes Integer ArrayField as string

[Django]

#33974: Serializer incorrectly serializes Integer ArrayField as string
-+-
 Reporter:  Arthur Hanson|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core |  Version:  4.0
  (Serialization)|
 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 Claude Paroz):

 Arthur, would you like to work on a possible fix? (with no guarantee it
 will be accepted eventually)

-- 
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/01070182fd804abf-c765b5fa-3cad-4b6e-b1f8-9d41e59c0f1e-00%40eu-central-1.amazonses.com.

Re: [Django] #33976: HTTP_HOST does not allow an ipv6 not enclosed in []

[Django]

#33976: HTTP_HOST does not allow an ipv6 not enclosed in []
-+--
 Reporter:  eburghar |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  ipv6 | 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 eburghar:

Old description:

> Hi,
>
> If I'm not mistaken, brackets are optional for an ipv6 address without
> port number. The problem is that it confuses django. In `asgi.py` we have
>
> ```
> Invalid HTTP_HOST header: '2001:x:y:z:0:0:0:1'. The domain name provided
> is not valid according to RFC 1034/1035.
> ```
>
> which can be fixed by changing `django.http.request.host_validation_re`
> to `_lazy_re_compile(r"[a-zA-z0-9.:]*")`
>
> but it also triggers an exception with `asgi.py`
>
> ```
> 2022/09/02 07:57:10 [alert] 422#422 [unit] Python failed to call
> 'loop.call_soon'
> Traceback (most recent call last):
>   File "/usr/lib/python3.10/asyncio/base_events.py", line 750, in
> call_soon
> self._check_closed()
> ValueError: invalid literal for int() with base 10: 'x:y:z:0:0:0:1'
> 2022/09/02 07:57:25 [alert] 422#422 [unit] #23: Python failed to create
> 'client' pair
> ```

New description:

 Hi,

 If I'm not mistaken, brackets are optional for an ipv6 address without
 port number. The problem is that it confuses django. In `asgi.py` we have

 {{{
 Invalid HTTP_HOST header: '2001:x:y:z:0:0:0:1'. The domain name provided
 is not valid according to RFC 1034/1035.
 }}}

 which can be fixed by changing `django.http.request.host_validation_re` to
 `_lazy_re_compile(r"[a-zA-z0-9.:]*")`

 but it also triggers an exception with `asgi.py`

 {{{
 2022/09/02 07:57:10 [alert] 422#422 [unit] Python failed to call
 'loop.call_soon'
 Traceback (most recent call last):
   File "/usr/lib/python3.10/asyncio/base_events.py", line 750, in
 call_soon
 self._check_closed()
 ValueError: invalid literal for int() with base 10: 'x:y:z:0:0:0:1'
 2022/09/02 07:57:25 [alert] 422#422 [unit] #23: Python failed to create
 'client' pair
 }}}

--

-- 
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/01070182fd7fef6b-212f4c02-98bf-4c51-8fa5-0d3b89cae543-00%40eu-central-1.amazonses.com.

[Django] #33976: HTTP_HOST does not allow an ipv6 not enclosed in []

[Django]

#33976: HTTP_HOST does not allow an ipv6 not enclosed in []
---+
   Reporter:  eburghar |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Core (URLs)  |Version:  3.2
   Severity:  Normal   |   Keywords:  ipv6
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Hi,

 If I'm not mistaken, brackets are optional for an ipv6 address without
 port number. The problem is that it confuses django. In `asgi.py` we have

 ```
 Invalid HTTP_HOST header: '2001:x:y:z:0:0:0:1'. The domain name provided
 is not valid according to RFC 1034/1035.
 ```

 which can be fixed by changing `django.http.request.host_validation_re` to
 `_lazy_re_compile(r"[a-zA-z0-9.:]*")`

 but it also triggers an exception with `asgi.py`

 ```
 2022/09/02 07:57:10 [alert] 422#422 [unit] Python failed to call
 'loop.call_soon'
 Traceback (most recent call last):
   File "/usr/lib/python3.10/asyncio/base_events.py", line 750, in
 call_soon
 self._check_closed()
 ValueError: invalid literal for int() with base 10: 'x:y:z:0:0:0:1'
 2022/09/02 07:57:25 [alert] 422#422 [unit] #23: Python failed to create
 'client' pair
 ```

-- 
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/01070182fd7e20bc-da2a23cf-fdc7-4230-bc1b-6c09866945ad-00%40eu-central-1.amazonses.com.

Re: [Django] #33975: Using .filter with lookup field__in=queryset where queryset contains .annotate and .alias fails

[Django]

#33975: Using .filter with lookup field__in=queryset where queryset contains
.annotate and .alias fails
-+-
 Reporter:  Gabriel Muj  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-

Comment (by Gabriel Muj):

 Using either {{{.alias}}} or {{{.annotate}}} works as expected without
 using {{{.values}}} to limit to 1 column. Why is that? but using both of
 them doesn't seem work.

-- 
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/01070182fd698a51-566df9b1-a81d-433a-9726-828ca1d76bb0-00%40eu-central-1.amazonses.com.

Re: [Django] #33975: Using .filter with lookup field__in=queryset where queryset contains .annotate and .alias fails

[Django]

#33975: Using .filter with lookup field__in=queryset where queryset contains
.annotate and .alias fails
-+-
 Reporter:  Gabriel Muj  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (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
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 This is a
 [https://docs.djangoproject.com/en/stable/ref/models/expressions/#limiting-a
 -subquery-to-a-single-column documented] and expected behavior.

-- 
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/01070182fd51f80f-652a26ca-b6aa-40fa-abfa-d40e90dca485-00%40eu-central-1.amazonses.com.

Re: [Django] #33975: Using .filter with lookup field__in=queryset where queryset contains .annotate and .alias fails

[Django]

#33975: Using .filter with lookup field__in=queryset where queryset contains
.annotate and .alias fails
-+-
 Reporter:  Gabriel Muj  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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
-+-
Changes (by Gabriel Muj):

 * component:  Uncategorized => Database layer (models, ORM)


-- 
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/01070182fd46bf19-601aeff1-d562-49cc-b59f-26f1b3c7cc32-00%40eu-central-1.amazonses.com.

[Django] #33975: Using .filter with lookup field__in=queryset where queryset contains .annotate and .alias fails

[Django]

#33975: Using .filter with lookup field__in=queryset where queryset contains
.annotate and .alias fails
-+
   Reporter:  gmuj   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  4.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  |
-+
 Here is a test case to reproduce the bug,  you can add this in
 tests/annotations/tests.py

 {{{#!python
 def test_annotation_and_alias_filter_in_subquery(self):
 long_books_qs = (
 Book.objects.filter(
 pages__gt=400,
 )
 .annotate(book_annotate=Value(1))
 .alias(book_alias=Value(1))
 )
 publisher_books_qs = (
 Publisher.objects.filter(
 book__in=long_books_qs
 )
 .values("name")
 )
 self.assertCountEqual(
 publisher_books_qs,
 [
 {'name': 'Apress'},
 {'name': 'Sams'},
 {'name': 'Prentice Hall'},
 {'name': 'Morgan Kaufmann'}
 ]
 )
 }}}

 You should get this error:

 {{{django.db.utils.OperationalError: sub-select returns 10 columns -
 expected 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/01070182fd3dbf8c-7c3e45cd-7a81-4ff3-84c3-ae3bff17b814-00%40eu-central-1.amazonses.com.

Re: [Django] #33974: Serializer incorrectly serializes Integer ArrayField as string

[Django]

#33974: Serializer incorrectly serializes Integer ArrayField as string
-+-
 Reporter:  Arthur Hanson|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core |  Version:  4.0
  (Serialization)|
 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 Mariusz Felisiak):

 Replying to [comment:2 Claude Paroz]:
 > FWIW, I would be favorable to fix this, if not too complex to do.

 PoC is always welcome, I'm afraid that this will brake existing fixtures.

-- 
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/01070182fd3d311f-cef1acc2-ecc6-42f3-b255-81315ded4b8e-00%40eu-central-1.amazonses.com.

Re: [Django] #29799: Allow registration and unregistration of lookups per field instances.

[Django]

#29799: Allow registration and unregistration of lookups per field instances.
-+-
 Reporter:  Simon Charette   |Owner:
 |  AllenJonathan
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  GSoC | 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/01070182fd3a0bd2-4be04f23-3841-4dbe-a82e-459ed8d4bdc0-00%40eu-central-1.amazonses.com.

Re: [Django] #33974: Serializer incorrectly serializes Integer ArrayField as string

[Django]

#33974: Serializer incorrectly serializes Integer ArrayField as string
-+-
 Reporter:  Arthur Hanson|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core |  Version:  4.0
  (Serialization)|
 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 Claude Paroz):

 FWIW, I would be favorable to fix this, if not too complex to do.

-- 
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/01070182fd2c1879-82a0dbb5-473b-47c0-8d97-62a0987263be-00%40eu-central-1.amazonses.com.

Re: [Django] #33662: Choose witch items are to be display per language in Sitemap

[Django]

#33662: Choose witch items are to be display per language in Sitemap
---+
 Reporter:  roxanebellot   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  sitemap| Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by PhönixGeist):

 I would like to tackle this new feature, it sounds interesting. As Carlton
 Gibson said, could you expand please the description, so I can fully
 understand the idea of the new feature?.

 For instance, on which scenario the URLs get translated? (Not sure, but
 this maybe sounds more like an error than a future).
 It does sound as a new feature, being able to display some items depending
 on the language, by this do you mean like for example, only translate a
 menu or only translate a what is inside a  or something similar?

 Please expand your idea.

-- 
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/01070182fcf3203b-e66e5e97-30b3-4a7b-8927-fd95576996ea-00%40eu-central-1.amazonses.com.