Re: [Django] #35309: Elide ordering of prefetch querysets for single valued relationships

[Django]

#35309: Elide ordering of prefetch querysets for single valued relationships
-+-
 Reporter:  Laurent Lyaudet  |Owner:  Laurent
 Type:   |  Lyaudet
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch single- | Triage Stage:  Accepted
  valued order_by|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Laurent Lyaudet:

Old description:

> While the ordering of multi-valued relationships must be preserved when
> prefetching relationships is it unnecessary when using `prefetch_related`
> against single valued relationships.
>
> For example, given the following models
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=200)
>
> class Meta:
> ordering = ["name"]
>

> class Book(models.Model):
> title = models.CharField(max_length=200)
> author = models.ForeignKey(Author, related_name="books",
> on_delete=models.CASCADE)
>
> class Meta:
> ordering = ["title"]
> }}}
>
> The ordering of an author's books in
> `Author.objects.prefetch_related("books")` has a significance as multiple
> books might be associated with each authors.
>
> It's not the case for a book's author in
> `Book.objects.prefetch_related("author")` through as the relationship can
> only contain a single author and there is a single way to order the
> members of a singleton.
>
> In other words `sorted([element], key=sort_func)` will result in
> `[element]` for any `sort_func`.
>
> This property holds true for all the single valued relationships that the
> ORM supports (backward and forward 1:1 and forward 1:M) which allows the
> prefetching to elide any predefined ordering safely to avoid an
> unnecessary and possibly expensive ordering defined for the related model
> queryset.
> Currently the prefetch of authors will use the order by and add useless
> charge on the DB server.
> It would be useful to remove this order by.
> #ClimateChangeBrake

New description:

 While the ordering of multi-valued relationships must be preserved when
 prefetching relationships is it unnecessary when using `prefetch_related`
 against single valued relationships.

 For example, given the following models

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
 ordering = ["name"]


 class Book(models.Model):
 title = models.CharField(max_length=200)
 author = models.ForeignKey(Author, related_name="books",
 on_delete=models.CASCADE)

 class Meta:
 ordering = ["title"]
 }}}

 The ordering of an author's books in
 `Author.objects.prefetch_related("books")` has a significance as multiple
 books might be associated with each authors.

 It's not the case for a book's author in
 `Book.objects.prefetch_related("author")` through as the relationship can
 only contain a single author and there is a single way to order the
 members of a singleton.

 In other words `sorted([element], key=sort_func)` will result in
 `[element]` for any `sort_func`.

 This property holds true for all the single valued relationships that the
 ORM supports (backward and forward 1:1 and forward 1:M) which allows the
 prefetching to elide any predefined ordering safely to avoid an
 unnecessary and possibly expensive ordering defined for the related model
 queryset.
 Currently the prefetch of authors will use the order by and add useless
 load on the DB server.
 It would be useful to remove this order by.
 #ClimateChangeBrake

--
-- 
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/0107018e492c814d-d1de3d6f-6425-44b4-a00c-f53ef6fb896d-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Elide ordering of prefetch querysets for single valued relationships

[Django]

#35309: Elide ordering of prefetch querysets for single valued relationships
-+-
 Reporter:  Laurent Lyaudet  |Owner:  Laurent
 Type:   |  Lyaudet
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch single- | Triage Stage:  Accepted
  valued order_by|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Laurent Lyaudet:

Old description:

> While the ordering of multi-valued relationships must be preserved when
> prefetching relationships is it unnecessary when using `prefetch_related`
> against single valued relationships.
>
> For example, given the following models
>
> {{{#!python
> class Author(models.Model):
> name = models.CharField(max_length=200)
>
> class Meta:
> ordering = ["name"]
>

> class Book(models.Model):
> title = models.CharField(max_length=200)
> author = models.ForeignKey(Author, related_name="books",
> on_delete=models.CASCADE)
>
> class Meta:
> ordering = ["title"]
> }}}
>
> The ordering of an author's books in
> `Author.objects.prefetch_related("books")` has a significance as multiple
> books might be associated with each authors.
>
> It's not the case for a book's author in
> `Book.objects.prefetch_related("author")` through as the relationship can
> only contain a single author and there is a single way to order the
> members of a singleton.
>
> In other words `sorted([element], key=sort_func)` will result in
> `[element]` for any `sort_func`.
>
> This property holds true for all the single valued relationships that the
> ORM supports (backward and forward 1:1 and forward 1:M) which allows the
> prefetching to elide any predefined ordering safely to avoid an
> unnecessary and possibly expensive ordering defined for the related model
> queryset.

New description:

 While the ordering of multi-valued relationships must be preserved when
 prefetching relationships is it unnecessary when using `prefetch_related`
 against single valued relationships.

 For example, given the following models

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
 ordering = ["name"]


 class Book(models.Model):
 title = models.CharField(max_length=200)
 author = models.ForeignKey(Author, related_name="books",
 on_delete=models.CASCADE)

 class Meta:
 ordering = ["title"]
 }}}

 The ordering of an author's books in
 `Author.objects.prefetch_related("books")` has a significance as multiple
 books might be associated with each authors.

 It's not the case for a book's author in
 `Book.objects.prefetch_related("author")` through as the relationship can
 only contain a single author and there is a single way to order the
 members of a singleton.

 In other words `sorted([element], key=sort_func)` will result in
 `[element]` for any `sort_func`.

 This property holds true for all the single valued relationships that the
 ORM supports (backward and forward 1:1 and forward 1:M) which allows the
 prefetching to elide any predefined ordering safely to avoid an
 unnecessary and possibly expensive ordering defined for the related model
 queryset.
 Currently the prefetch of authors will use the order by and add useless
 charge on the DB server.
 It would be useful to remove this order by.
 #ClimateChangeBrake

--
-- 
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/0107018e48c95662-589e23b4-843a-40c6-936c-07501ca83631-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Elide ordering of prefetch querysets for single valued relationships

[Django]

#35309: Elide ordering of prefetch querysets for single valued relationships
-+-
 Reporter:  Laurent Lyaudet  |Owner:  Laurent
 Type:   |  Lyaudet
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch single- | Triage Stage:  Accepted
  valued order_by|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Laurent Lyaudet):

 Hello,


 Thanks for the replies and the constructive suggested improvements.


 I removed `_do_not_modify_order_by`.


 I improved to avoid an useless cloning of `QuerySet`.
 For that I created a protected method
 `QuerySet._in_place_empty_order_by()` just below `QuerySet.order_by()`.
 I thought it would be the best solution without modifying the "public API"
 of `QuerySet`.
 Another solution could be to add kwargs to `QuerySet.order_by()` like :
 - `clone: bool = True`, or `no_clone: bool = False`, or `in_place: bool =
 False`,
 - and maybe `clear_default: bool = False`.
 But it would require a larger discussion I think.
 If you think the name of `QuerySet._in_place_empty_order_by()` should be
 changed for something else, tell me.


 Regarding the tests, thanks for the suggestions.
 I applied them in my two tests.
 I think this is better practice to have two separate tests where the
 intent of each test is clear.
 And I haven't added the asserts in other tests.
 However, I understand that you may want to avoid cluttering the tests and
 the models in `tests/prefetch_related/models.py`.
 I have see that I can replace the class `A35309` with the class `Book` and
 the class `B35309` with the class `Author` in my first test.
 Tell me if you think I should do that.
 I have see that I can replace the class `A35309` with the class `Room` and
 the class `C35309` with the class `House` in my second test.
 Tell me if you think I should do that.

 Best regards,
  Laurent Lyaudet
-- 
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/0107018e48962424-7674d820-9786-4069-98ae-9f5ff2518da9-00%40eu-central-1.amazonses.com.

Re: [Django] #27106: Document which template filters can be used in Python code (and how)

[Django]

#27106: Document which template filters can be used in Python code (and how)
-+-
 Reporter:  Baptiste Mispelon|Owner:  Ryan
 Type:   |  Cheley
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 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 Ryan Cheley):

 * owner:  (none) => Ryan Cheley
 * status:  new => assigned

Comment:

 Before I start working on this ticket I wanted to make sure that it was
 still needed / valid. I can pick up the work that was done previously and
 try to get it over the finish line.
-- 
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/0107018e481b1ee7-fe615dc5-af4b-4c88-9ec4-9f1389623a2f-00%40eu-central-1.amazonses.com.

Re: [Django] #31014: add FromWKB and FromWKT GIS functions

[Django]

#31014: add FromWKB and FromWKT GIS functions
-+
 Reporter:  Sergey Fedoseev  |Owner:  Claude Paroz
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  wkt, wkb | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Claude Paroz):

 * needs_better_patch:  1 => 0
 * needs_docs:  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/0107018e4816e7da-89163746-a65d-4be4-870e-426fda1688fd-00%40eu-central-1.amazonses.com.

Re: [Django] #35278: `ngettext` result can be possibly undefined.

[Django]

#35278: `ngettext` result can be possibly undefined.
-+-
 Reporter:  Piotr Kawula |Owner:  Piotr
 |  Kawula
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  ngettext,catalog,i18n,internationalization,|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * has_patch:  0 => 1
 * 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/0107018e4804d7d7-7443a992-1bdd-4b67-ad73-c42e140a12b0-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Elide ordering of prefetch querysets for single valued relationships

[Django]

#35309: Elide ordering of prefetch querysets for single valued relationships
-+-
 Reporter:  Laurent Lyaudet  |Owner:  Laurent
 Type:   |  Lyaudet
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch single- | Triage Stage:  Accepted
  valued order_by|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Laurent Lyaudet
 * 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/0107018e47ba6f41-cb9b61b8-3e0c-4f30-9eff-2d2f72cd316b-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Elide ordering of prefetch querysets for single valued relationships (was: Remove Order by on models when prefetching by id)

[Django]

#35309: Elide ordering of prefetch querysets for single valued relationships
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch single- | Triage Stage:  Accepted
  valued order_by|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)
 * keywords:  prefetch order_by => prefetch single-valued order_by
 * needs_better_patch:  0 => 1
 * resolution:  wontfix =>
 * stage:  Unreviewed => Accepted
 * status:  closed => new
 * summary:  Remove Order by on models when prefetching by id => Elide
 ordering of prefetch querysets for single valued relationships


Old description:

> Hello,
>
> I don't know if the "bug" is still here with Django 5.
> But on my version of Django, I have the following "bug" :
> Assume you have the following code :
>
> {{{#!python
> class A(models.Model):
> name = models.CharField(max_length=200)
>
> class Meta:
> ordering = ["name"]
>

> class B(models.Model):
> a = models.ForeignKey(A, related_name="bs", on_delete=models.CASCADE)
>

> a1 = A.objects.create(name="a1")
> a2 = A.objects.create(name="a2")
> a3 = A.objects.create(name="a3")
> a4 = A.objects.create(name="a4")
> a5 = A.objects.create(name="a5")
> a6 = A.objects.create(name="a6")
> a7 = A.objects.create(name="a7")
>
> b1 = B.objects.create(a=a1)
> b2 = B.objects.create(a=a2)
> b3 = B.objects.create(a=a3)
> b4 = B.objects.create(a=a4)
> b5 = B.objects.create(a=a5)
> b6 = B.objects.create(a=a6)
> b7 = B.objects.create(a=a7)
>
> bs = B.objects.all().prefetch_related("a")
> }}}
>
> The prefetch of as will use the order by and add useless charge on the DB
> server.
> There may be other cases than ForeignKey where the order by is useless.
> But since OneToOne inherits from ForeignKey, I don't see anything else
> right now.
>
> Hence, I request this enhancement, please :)
> #ClimateChangeBrake
>
> Best regards,
> Laurent Lyaudet

New description:

 While the ordering of multi-valued relationships must be preserved when
 prefetching relationships is it unnecessary when using `prefetch_related`
 against single valued relationships.

 For example, given the following models

 {{{#!python
 class Author(models.Model):
 name = models.CharField(max_length=200)

 class Meta:
 ordering = ["name"]


 class Book(models.Model):
 title = models.CharField(max_length=200)
 author = models.ForeignKey(Author, related_name="books",
 on_delete=models.CASCADE)

 class Meta:
 ordering = ["title"]
 }}}

 The ordering of an author's books in
 `Author.objects.prefetch_related("books")` has a significance as multiple
 books might be associated with each authors.

 It's not the case for a book's author in
 `Book.objects.prefetch_related("author")` through as the relationship can
 only contain a single author and there is a single way to order the
 members of a singleton.

 In other words `sorted([element], key=sort_func)` will result in
 `[element]` for any `sort_func`.

 This property holds true for all the single valued relationships that the
 ORM supports (backward and forward 1:1 and forward 1:M) which allows the
 prefetching to elide any predefined ordering safely to avoid an
 unnecessary and possibly expensive ordering defined for the related model
 queryset.

--
Comment:

 I'm sorry for the awkward back and forth here but reviewing Laurent's PR
 made something clear to me that wasn't from the origin report.

 The requested optimization here is solely for single valued relationships
 (backward and forward 1:1 and forward 1:M). In this scenario, as pointed
 out by Laurent, `ORDER BY` doesn't matter as the related collection is
 either empty or a singleton and thus `order_by()` can always be used in
 their respective `get_prefetch_queryset`.

 In the light of this realization I've adjusted the report and moved back
 this ticket to an accepted optimization.

 Laurent, as for the patch I suggest simply decorating existing tests that
 make use of prefetching for single valued relationship (there are plenty
 in `prefetch_related` tests`) which `assertNumQueries` and use the context
 queries to assert against the lack of `ORDER BY`.

 e.g.

 {{{#!python
 with self.assertNumQueries(2) as ctx:
list(Book.objects.prefetch_related("author"))
 self.assertNotIn("ORDER BY", ctx.queries[-1]

Re: [Django] #35301: Overriding a @property of an abstract model with a GenericRelation causes a models.E025 error.

[Django]

#35301: Overriding a @property of an abstract model with a GenericRelation 
causes a
models.E025 error.
-+-
 Reporter:  Sage Abdullah|Owner:  Adam
 |  Johnson
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Johnson):

 * has_patch:  0 => 1
 * owner:  nobody => Adam Johnson
 * 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/0107018e47348572-da635dfd-6020-45d8-9422-8a92d334d6ea-00%40eu-central-1.amazonses.com.

Re: [Django] #35312: staticurl_urlpatterns incorrectly uses STATIC_URL that prefixed using SCRIPT_NAME

[Django]

#35312: staticurl_urlpatterns incorrectly uses STATIC_URL that prefixed using
SCRIPT_NAME
-+-
 Reporter:  yudhiwidyatama   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yudhiwidyatama):

 * Attachment "urls.py" added.

 this is my change suggestion in contrib/staticfiles/urls.py
-- 
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/0107018e46f54cac-f37c6e0d-3e57-4a77-88ed-154dfe2a21fd-00%40eu-central-1.amazonses.com.

[Django] #35312: staticurl_urlpatterns incorrectly uses STATIC_URL that prefixed using SCRIPT_NAME

[Django]

#35312: staticurl_urlpatterns incorrectly uses STATIC_URL that prefixed using
SCRIPT_NAME
---+
   Reporter:  yudhiwidyatama   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  contrib.staticfiles  |Version:  5.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|
---+
 Deploying Django using Gunicorn with SCRIPT_NAME set to '/django', we get
 the url for static resources are correctly generated with
 '/django/static/' prefix, but the static url patterns is also prefixed
 with the '/django/static/'. This is wrong because url patterns will be
 compared with the PATH_INFO part of the URL without the script_name
 prefix.

 Reproduce step :
 1. create a django app with static directory containing image or css
 files.
 2. append static url pattern to site's urls.py by either appending
 urlpatterns += staticfiles_urlpatterns()
 or
 urlpatterns += static(settings.STATIC_URL,
 document_root=settings.STATIC_ROOT)
 (refer: https://docs.djangoproject.com/en/5.0/howto/static-files/)
 3. serve using gunicorn by previously setting SCRIPT_NAME environment
 variable to /django
 4. access the url served by gunicorn
 (http://localhost:8000/django/)
 5. the application urls are served under /django prefix, the generated
 static urls also having the /django/static prefix.
 6. accessing application url, gunicorn correctly renders pages, but not
 the static content

 suggestion :
 a. change staticfiles_urlpatterns() in contrib/staticfiles/urls.py  to
 check whether the urlpatterns prefix starts with get_script_prefix(), and
 if so, strip the get_script_prefix() part from prefix
 b. or change the settings.STATIC_URL in the howto page with expression
 that strips the SCRIPT_NAME part or get_script_prefix() part.
-- 
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/0107018e46f4200b-7bb91f4d-9e58-41ad-aaf5-283d115cd214-00%40eu-central-1.amazonses.com.

Re: [Django] #35307: make async generic views

[Django]

#35307: make async generic views
+--
 Reporter:  amirreza|Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Generic views   |  Version:  dev
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  async, generic  | 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):

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

Comment:

 Class-based views already allow defining async method handlers, check out
 [https://docs.djangoproject.com/en/dev/topics/class-based-views
 /#asynchronous-class-based-views docs].
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e46dc6b1f-6ced695c-e0c1-4d78-8838-3ca75581dd52-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Comment:

 Laurent, thanks for this patch, however I agree with Simon.

 I appreciate you'd like to reopen the ticket, but please
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow the triaging guidelines with regards to
 wontfix tickets] and take this to DevelopersMailingList.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e46d52203-b962cbd6-e7a0-4771-b2cb-3d4289588dd4-00%40eu-central-1.amazonses.com.

Re: [Django] #35262: Addindex operation generates wrong sql code for Postgresql GinIndex

[Django]

#35262: Addindex operation generates wrong sql code for Postgresql GinIndex
--+--
 Reporter:  Pierre Juhen  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  5.0
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Tim Graham):

 * resolution:  worksforme => duplicate

Comment:

 Duplicate of #33021. `django.contrib.postgres` must be in `INSTALLED_APPS`
 when using `OpClass()`. See
 [https://docs.djangoproject.com/en/stable/ref/contrib/postgres/indexes
 /#opclass-expressions docs] and related ticket #32770.
-- 
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/0107018e46d01f76-09450740-1c40-438d-899d-7d121427170a-00%40eu-central-1.amazonses.com.

Re: [Django] #35311: Addindex operation generates wrong sql code for Postgresql GinIndex

[Django]

#35311: Addindex operation generates wrong sql code for Postgresql GinIndex
-+-
 Reporter:  Pierre Juhen |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgresql   | Triage Stage:
  migration  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Old description:

> Hi,
>
> I created a Gin Index using :
>
> ''GinIndex(OpClass(Lower('title'),  name='gin_trgm_ops'),
> name="name_gin_trgm_title_affaire"),''
>
> makemigrations generates the following code :
>
> ''migrations.AddIndex(
>'' model_name='affaire',
> index=django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(django.db.models.functions.text.Lower('title'),
> name='gin_trgm_ops'), name='name_gin_trgm_title_affaire'),''
> ),''
>
> SQLMIGRATE generates a wrong code :
>
> ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
> gin ((LOWER("title"), name=gin_trgm_ops));''
>
> Instead of (too many parenthesis) :
>
> ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
> gin (LOWER("title"),  name=gin_trgm_ops);''
>
> There is a manual workaround, but its annoying.
>
> Thank you.
>
> Regards

New description:

 Hi,

 I created a Gin Index using :

 {{{
 GinIndex(OpClass(Lower('title'),  name='gin_trgm_ops'),
 name="name_gin_trgm_title_affaire"),'
 }}}

 makemigrations generates the following code :

 {{{
 migrations.AddIndex(
'' model_name='affaire',
 
index=django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(django.db.models.functions.text.Lower('title'),
 name='gin_trgm_ops'), name='name_gin_trgm_title_affaire'),''
 ),''
 }}}
 SQLMIGRATE generates a wrong code :

 {{{
 CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING gin
 ((LOWER("title"), name=gin_trgm_ops));''
 }}}
 Instead of (too many parenthesis) :

 {{{
 CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING gin
 (LOWER("title"),  name=gin_trgm_ops);''
 }}}

 There is a manual workaround, but its annoying.

 Thank you.

 Regards

--
Comment:

 Duplicate of #33021. `django.contrib.postgres` must be in `INSTALLED_APPS`
 when using `OpClass()`. See
 [https://docs.djangoproject.com/en/stable/ref/contrib/postgres/indexes
 /#opclass-expressions docs] and related ticket #32770.
-- 
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/0107018e46cf943e-a298c6e4-2233-4eef-b3cd-90d1b5b23d58-00%40eu-central-1.amazonses.com.

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
-+
 Reporter:  Sergey Fedoseev  |Owner:  Tom L.
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  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 Tom L.):

 * needs_tests:  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/0107018e46c8268a-be35b7bd-f9b9-4d2a-a214-9af9bc51958b-00%40eu-central-1.amazonses.com.

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

[Django]

#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  Tom L.
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Accepted
  createmigrations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom L.):

 * needs_better_patch:  1 => 0
 * needs_tests:  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/0107018e46c7c947-92be287b-5604-481b-8d78-4d27cc1c6785-00%40eu-central-1.amazonses.com.

Re: [Django] #35311: Addindex operation generates wrong sql code for Postgresql GinIndex

[Django]

#35311: Addindex operation generates wrong sql code for Postgresql GinIndex
-+-
 Reporter:  Pierre Juhen |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql   | Triage Stage:
  migration  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Pierre Juhen:

Old description:

> Hi,
>
> I created a Gin Index using :
>
> ''GinIndex(OpClass(Lower('title'),  name='gin_trgm_ops'),
> name="name_gin_trgm_title_affaire"),''
>
> makemigrations generates the following code :
>
> ''migrations.AddIndex(
>'' model_name='affaire',
> index=django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(django.db.models.functions.text.Lower('title'),
> name='gin_trgm_ops'), name='name_gin_trgm_title_affaire'),''
> ),''
>
> SQLMIGRATE generates a wrong code :
>
> ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
> gin ((LOWER("title")));''
>
> Instead of (too many parenthesis) :
>
> ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
> gin (LOWER("title"));''
>
> There is a manual workaround, but its annoying.
>
> Thank you.
>
> Regards

New description:

 Hi,

 I created a Gin Index using :

 ''GinIndex(OpClass(Lower('title'),  name='gin_trgm_ops'),
 name="name_gin_trgm_title_affaire"),''

 makemigrations generates the following code :

 ''migrations.AddIndex(
'' model_name='affaire',
 
index=django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(django.db.models.functions.text.Lower('title'),
 name='gin_trgm_ops'), name='name_gin_trgm_title_affaire'),''
 ),''

 SQLMIGRATE generates a wrong code :

 ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
 gin ((LOWER("title"), name=gin_trgm_ops));''

 Instead of (too many parenthesis) :

 ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
 gin (LOWER("title"),  name=gin_trgm_ops);''

 There is a manual workaround, but its annoying.

 Thank you.

 Regards

--
-- 
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/0107018e466a4a2e-76dd1fcd-ef4e-4357-a7b7-34f0c4ab7c57-00%40eu-central-1.amazonses.com.

[Django] #35311: Addindex operation generates wrong sql code for Postgresql GinIndex

[Django]

#35311: Addindex operation generates wrong sql code for Postgresql GinIndex
-+-
   Reporter:  Pierre |  Owner:  nobody
  Juhen  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.0
  layer (models, ORM)|   Keywords:  postgresql
   Severity:  Normal |  migration
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 I created a Gin Index using :

 ''GinIndex(OpClass(Lower('title'),  name='gin_trgm_ops'),
 name="name_gin_trgm_title_affaire"),''

 makemigrations generates the following code :

 ''migrations.AddIndex(
'' model_name='affaire',
 
index=django.contrib.postgres.indexes.GinIndex(django.contrib.postgres.indexes.OpClass(django.db.models.functions.text.Lower('title'),
 name='gin_trgm_ops'), name='name_gin_trgm_title_affaire'),''
 ),''

 SQLMIGRATE generates a wrong code :

 ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
 gin ((LOWER("title")));''

 Instead of (too many parenthesis) :

 ''CREATE INDEX "name_gin_trgm_title_affaire" ON "affaires_affaire" USING
 gin (LOWER("title"));''

 There is a manual workaround, but its annoying.

 Thank you.

 Regards
-- 
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/0107018e46648af5-3399de75-a558-4441-9da1-e8cf9d6707e8-00%40eu-central-1.amazonses.com.

Re: [Django] #35309: Remove Order by on models when prefetching by id

[Django]

#35309: Remove Order by on models when prefetching by id
-+-
 Reporter:  Laurent Lyaudet  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch order_by| Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Laurent Lyaudet):

 Here is the PR, I will improve it when requested :
 https://github.com/django/django/pull/17984 :)
 I still have doubts about keeping the order by even with manual Prefetch.
 I need to verify if it is possible to bypass the filter by id.
-- 
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/0107018e4618a810-2a3b464f-cb6d-4f53-a5fd-e860d41b382b-00%40eu-central-1.amazonses.com.