Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cf95de9d24c987beff51b54979c02aeef1f98050" cf95de9]:
 {{{
 #!CommitTicketReference repository=""
 revision="cf95de9d24c987beff51b54979c02aeef1f98050"
 [4.2.x] Fixed #34987 -- Fixed queryset crash when mixing aggregate and
 window annotations.

 Regression in f387d024fc75569d2a4a338bfda76cc2f328f627.

 Just like `OrderByList` the `ExpressionList` expression used to wrap
 `Window.partition_by` must implement `get_group_by_cols` to ensure the
 necessary grouping when mixing window expressions with aggregate
 annotations is performed against the partition members and not the
 partition expression itself.

 This is necessary because while `partition_by` is implemented as
 a source expression of `Window` it's actually a fragment of the WINDOW
 expression at the SQL level and thus it should result in a group by its
 members and not the sum of them.

 Thanks ElRoberto538 for the report.
 Backport of e76cc93b0168fa3abbafb9af1ab4535814b751f0 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/0107018bfa965f43-c6c127c8-495a-4cce-9c01-b20767b159da-00%40eu-central-1.amazonses.com.

Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"95dec210e89a2fb46ffde2ba29ff7876e1d5f86e" 95dec21]:
 {{{
 #!CommitTicketReference repository=""
 revision="95dec210e89a2fb46ffde2ba29ff7876e1d5f86e"
 [5.0.x] Fixed #34987 -- Fixed queryset crash when mixing aggregate and
 window annotations.

 Regression in f387d024fc75569d2a4a338bfda76cc2f328f627.

 Just like `OrderByList` the `ExpressionList` expression used to wrap
 `Window.partition_by` must implement `get_group_by_cols` to ensure the
 necessary grouping when mixing window expressions with aggregate
 annotations is performed against the partition members and not the
 partition expression itself.

 This is necessary because while `partition_by` is implemented as
 a source expression of `Window` it's actually a fragment of the WINDOW
 expression at the SQL level and thus it should result in a group by its
 members and not the sum of them.

 Thanks ElRoberto538 for the report.
 Backport of e76cc93b0168fa3abbafb9af1ab4535814b751f0 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/0107018bfa961851-2901d20e-ecca-4b43-ac75-dd9d2ee9e0ca-00%40eu-central-1.amazonses.com.

Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"e76cc93b0168fa3abbafb9af1ab4535814b751f0" e76cc93b]:
 {{{
 #!CommitTicketReference repository=""
 revision="e76cc93b0168fa3abbafb9af1ab4535814b751f0"
 Fixed #34987 -- Fixed queryset crash when mixing aggregate and window
 annotations.

 Regression in f387d024fc75569d2a4a338bfda76cc2f328f627.

 Just like `OrderByList` the `ExpressionList` expression used to wrap
 `Window.partition_by` must implement `get_group_by_cols` to ensure the
 necessary grouping when mixing window expressions with aggregate
 annotations is performed against the partition members and not the
 partition expression itself.

 This is necessary because while `partition_by` is implemented as
 a source expression of `Window` it's actually a fragment of the WINDOW
 expression at the SQL level and thus it should result in a group by its
 members and not the sum of them.

 Thanks ElRoberto538 for the report.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bfa950f3a-ccf051b4-9545-4a46-95fb-10b95fe9b24e-00%40eu-central-1.amazonses.com.

Re: [Django] #26827: "ModelState.fields cannot refer to a model class ... Use a string reference instead." when using custom model field derived from ManyToMany

[Django]

#26827: "ModelState.fields cannot refer to a model class ... Use a string 
reference
instead." when using custom model field derived from ManyToMany
-+-
 Reporter:  Rich Rauenzahn   |Owner:  Prashant
 Type:   |  Pandey
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Prashant Pandey):

 * has_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/0107018bfa8fe717-9249ce6e-d5f0-49fc-aa1b-7ed8ed803255-00%40eu-central-1.amazonses.com.

Re: [Django] #26827: "ModelState.fields cannot refer to a model class ... Use a string reference instead." when using custom model field derived from ManyToMany

[Django]

#26827: "ModelState.fields cannot refer to a model class ... Use a string 
reference
instead." when using custom model field derived from ManyToMany
-+-
 Reporter:  Rich Rauenzahn   |Owner:  Prashant
 Type:   |  Pandey
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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
-+-

Comment (by Prashant Pandey):

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

-- 
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/0107018bfa8eeb12-74a77b27-8eca-4a07-bf26-ae4b344480c8-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: Set Content-Length where possible for HttpResponses. (was: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket)

[Django]

#34989: Set Content-Length where possible for HttpResponses.
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  new
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:  Accepted
  uWSGI  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  1 => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepted.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bfa872a1b-55486170-2a61-4812-8e3e-53b519358372-00%40eu-central-1.amazonses.com.

Re: [Django] #34991: Wrong layout of pagination buttons with editable list in the admin.

[Django]

#34991: Wrong layout of pagination buttons with editable list in the admin.
-+---
 Reporter:  Rafał Safin  |Owner:  Rafał Safin
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSS,admin| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+---
Changes (by Mariusz Felisiak):

 * Attachment "django41.png" 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/0107018bfa82447c-d2cc1ec4-7f59-4827-a951-b583ea0f2364-00%40eu-central-1.amazonses.com.

Re: [Django] #34991: Wrong layout of pagination buttons with editable list in the admin.

[Django]

#34991: Wrong layout of pagination buttons with editable list in the admin.
-+---
 Reporter:  Rafał Safin  |Owner:  Rafał Safin
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSS,admin| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+---
Changes (by Mariusz Felisiak):

 * Attachment "django42.png" 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/0107018bfa822ac6-f9c76486-5838-493e-9291-21d94b988f96-00%40eu-central-1.amazonses.com.

Re: [Django] #34991: Wrong layout of pagination buttons with editable list in the admin. (was: Small admin panel css bug in pagination styles)

[Django]

#34991: Wrong layout of pagination buttons with editable list in the admin.
-+---
 Reporter:  Rafał Safin  |Owner:  Rafał Safin
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  CSS,admin| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+---
Changes (by Mariusz Felisiak):

 * severity:  Normal => Release blocker
 * cc: Alexander Freyr Lúðvíksson, Tom Carrick, Thibaud Colas (added)
 * needs_better_patch:  0 => 1
 * version:  dev => 4.2
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. This is a visual regression in
 b4817d20b9e55df30be0b1b2ca8c8bb6d61aab07. I don't think that fixing an
 alignment of `this-page` is enough, we should restore the pre-Django 4.2
 look:

-- 
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/0107018bfa81d7f0-70a7a6c8-de5e-4211-a140-5b249819859b-00%40eu-central-1.amazonses.com.

Re: [Django] #34990: Change external link for CSRF reference docs to OWASP

[Django]

#34990: Change external link for CSRF reference docs to OWASP
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  csrf,| Triage Stage:  Accepted
  documentation, owasp   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"6d7313bc870b0a37287dc7e3b30b1b5583c9ef0e" 6d7313bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d7313bc870b0a37287dc7e3b30b1b5583c9ef0e"
 [4.2.x] Fixed #34990 -- Changed link to OWASP in CSRF docs.

 The OWASP site is the standard resource for web application
 security information.
 Backport of aceee39d44994df20d13104e55ae61845d7a1e95 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/0107018bfa702293-c8f2a39a-c166-481c-9138-ae106791b1c5-00%40eu-central-1.amazonses.com.

Re: [Django] #34990: Change external link for CSRF reference docs to OWASP

[Django]

#34990: Change external link for CSRF reference docs to OWASP
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  csrf,| Triage Stage:  Accepted
  documentation, owasp   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"06bdf62b56a7cbd37a74b590587a8ae51b206321" 06bdf62b]:
 {{{
 #!CommitTicketReference repository=""
 revision="06bdf62b56a7cbd37a74b590587a8ae51b206321"
 [5.0.x] Fixed #34990 -- Changed link to OWASP in CSRF docs.

 The OWASP site is the standard resource for web application
 security information.
 Backport of aceee39d44994df20d13104e55ae61845d7a1e95 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/0107018bfa6ff2a5-e8961112-86cb-4dc3-8cd1-df6be6eb4521-00%40eu-central-1.amazonses.com.

Re: [Django] #34990: Change external link for CSRF reference docs to OWASP

[Django]

#34990: Change external link for CSRF reference docs to OWASP
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  csrf,| Triage Stage:  Accepted
  documentation, owasp   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"aceee39d44994df20d13104e55ae61845d7a1e95" aceee39d]:
 {{{
 #!CommitTicketReference repository=""
 revision="aceee39d44994df20d13104e55ae61845d7a1e95"
 Fixed #34990 -- Changed link to OWASP in CSRF docs.

 The OWASP site is the standard resource for web application
 security information.
 }}}

-- 
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/0107018bfa6ef43f-ca26fca9-7b0e-44a7-9187-69f58a384663-00%40eu-central-1.amazonses.com.

Re: [Django] #34990: Change external link for CSRF reference docs to OWASP

[Django]

#34990: Change external link for CSRF reference docs to OWASP
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  csrf,| Triage Stage:  Accepted
  documentation, owasp   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bfa6d4eb2-74e908ef-d82b-41be-ab7e-f52aa7233b50-00%40eu-central-1.amazonses.com.

Re: [Django] #34991: Small admin panel css bug in pagination styles

[Django]

#34991: Small admin panel css bug in pagination styles
---+---
 Reporter:  Rafał Safin|Owner:  Rafał Safin
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords:  CSS,admin  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+---
Changes (by Rafał Safin):

 * owner:  nobody => Rafał Safin
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

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

-- 
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/0107018bf93b5cb2-95c1a72b-a7c5-4dd7-9317-6d388d8f8059-00%40eu-central-1.amazonses.com.

Re: [Django] #34991: Small admin panel css bug in pagination styles

[Django]

#34991: Small admin panel css bug in pagination styles
---+--
 Reporter:  Rafał Safin|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords:  CSS,admin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by Rafał Safin):

 * Attachment "Screenshot from 2023-11-22 23-27-10.png" 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/0107018bf9371251-c939fbda-c4fa-411a-9f15-421b4b73e2fe-00%40eu-central-1.amazonses.com.

[Django] #34991: Small admin panel css bug in pagination styles

[Django]

#34991: Small admin panel css bug in pagination styles
-+---
   Reporter:  Rafał Safin|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  dev
   Severity:  Normal |   Keywords:  CSS,admin
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+---
 Hello, there is a small bug in Admin panel pagination css style.

 To reproduce, one must register model in Admin panel with at least one
 item in **list_editable** attribute (so the "Save" button will show up).
 It seems **.this-page** class has vertical align top and because button is
 large, it doesn't fit. Fix is to use vertical-align: middle, as far as i
 can see, this is the only place where this class is used.

 currently:
 https://user-images.githubusercontent.com/51059348/285057879-100f638f-
 5b6a-4ec7-afc5-588064cc9a84.png

 after fix:
 https://user-
 
images.githubusercontent.com/51059348/285059957-61c41c7f-0784-49f0-bdd8-16d5d6f263c2.png

-- 
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/0107018bf9360d29-734cac29-14e6-4231-833f-8bf04980c797-00%40eu-central-1.amazonses.com.

Re: [Django] #34990: Change external link for CSRF reference docs to OWASP

[Django]

#34990: Change external link for CSRF reference docs to OWASP
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 Type:   |  Schilling
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  csrf,| Triage Stage:
  documentation, owasp   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Timothy Schilling):

 * has_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/0107018bf9094328-7ca07d24-2511-4a8c-b86c-eb19c3266c96-00%40eu-central-1.amazonses.com.

Re: [Django] #34988: Makemigrations shouldn't prompt for default values for non-nullable fields of other apps.

[Django]

#34988: Makemigrations shouldn't prompt for default values for non-nullable 
fields
of other apps.
+
 Reporter:  Sarah Boyce |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Migrations  |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  makemigrations  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Sarah Boyce):

 * cc: Bhuvnesh (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/0107018bf8df8144-6b3b3104-e987-49be-8f58-4d143d7ddb17-00%40eu-central-1.amazonses.com.

Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_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/0107018bf8dd4bb6-20fdd8ca-29cb-4965-b9e9-4fd9c6a5c088-00%40eu-central-1.amazonses.com.

Re: [Django] #34978: Annotating through an aggregate with RawSQL() raises 1056 "Can't group on" on MySQL/MariaDB.

[Django]

#34978: Annotating through an aggregate with RawSQL() raises 1056 "Can't group 
on"
on MySQL/MariaDB.
-+-
 Reporter:  Matthew Somerville   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   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):

 > it looks like the code will not work at all with MariaDB with
 ONLY_FULL_GROUP_BY turned on.

 That's good to know thanks for investigating further that's appreciated! I
 think it's worth having a separate ticket for it yes. The solution will
 likely be to turn off the `allows_group_by_selected_pks` feature on
 MariaDB when `ONLY_FULL_GROUP_BY` mode is turned on. Note that the
 `allows_group_by_selected_pks` feature is different from the
 `allows_group_by_pk` feature removed in
 041551d716b69ee7c81199eee86a2d10a72e15ab.

-- 
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/0107018bf8aec398-c01ee2ab-27b9-4b27-9609-df07115019ca-00%40eu-central-1.amazonses.com.

Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned


Comment:

 I'm pretty sure that the issue is due to `Window`'s output field resolving
 is considering `partition_by` as part of its output when it shouldn't.

-- 
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/0107018bf8a5e024-000f0ce2-12bf-4055-b684-4d650cf2a1cb-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Florian Apolloner):

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


Comment:

 Yeah, in general I'd expect the server to optimize where possible, so it
 is rather surprising that uWSGI doesn't do that.

 It is unfortunate that `HttpResponse` does not have a `__len__` and we
 cannot monkey patch it onto it while also supporting streaming via
 generators without a known length because Python does something along the
 lines of `type(x).__len__(obj)`, so even if `hasattr()` sees `__len__`,
 calling `len()` on it works only if the class has `__len__`.

 I also guess we might not exactly be able to get rid of setting the
 `Content-Length` in the `CommonMiddleware` because we document it:
 https://docs.djangoproject.com/en/4.2/ref/middleware/#module-
 django.middleware.common

 So the way I see it we have two options:

  * Improve the `CommonMiddleware` as in your PR (I am saying improve and
 not fix, because technically Django does nothing spec incompatible, so it
 is rather a performance improvement. No matter how we spin it, there is a
 deeper bug in uWSGI I think -- this also means there will be no
 backports).

  * Also add a similar code to our WSGI/ASGI handlers and set the `Content-
 Length` where possible. I am in favor of doing this, since Anders is right
 that a server cannot optimize given that `HttpResponse` has no `__len__`.
 I am slighty worried about backwards compatibility here though, but I
 honestly cannot think of a case where setting the `Content-Length` would
 cause problems.

 As such I am preliminarily reopening the ticket and if Mariusz is fine
 with it let's set it to accepted. The title etc will be a little bit off
 then, but I guess that is fine.

 Would you mind opening a ticket against uWSGI and cross-link it here?

-- 
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/0107018bf89dc315-303a2131-c980-400b-96c4-1b28ffde43af-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Anders Kaseorg):

 To be clear, uWSGI doesn’t currently implement the `__len__` optimization
 and the spec doesn’t require it. So that’s another path that would require
 changing both Django and uWSGI, with the disadvantage that only some WSGI
 gateways would benefit.

-- 
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/0107018bf8932122-c897a741-c002-4a1d-b3da-3e7ee66ace11-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 I just looked at the PR and there might be a point to move
 
https://github.com/andersk/django/blob/de1ee5ee0ba51229ec8ceb7146173533f45ace51/django/middleware/common.py#L114
 into our WSGI handler because the middleware does not have to be active.
 Whether this would mean that `HTTPResponse` should have a `__len__` or we
 simply add logic in the wsgi handler, I am not sure yet. The PR as it
 stands now is not the proper fix though I think.

-- 
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/0107018bf8756271-debcdeaf-0884-4b88-8519-d1624e90f0d9-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Anders Kaseorg):

 So let’s fix it in both Django and uWSGI? Even after uWSGI is fixed, we
 want Django to send `Content-Length` anyway when possible, because
 `Content-Length` is more efficient than the alternatives, and uWSGI isn’t
 in a position to generate `Content-Length` because `HttpResponse` doesn’t
 have a `len()`.

-- 
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/0107018bf872dada-f10f3913-a51b-4ead-96cf-48fa26600d70-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
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:   => invalid


Comment:

 I agree with Florian that it's not an issue in Django itself. This should
 be reported and fixes in uWSGI.

-- 
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/0107018bf86ff2c8-9a78c97e-b821-4e45-99d4-899dd8ae87b1-00%40eu-central-1.amazonses.com.

Re: [Django] #34633: Add prefetch_related() cache invalidation for create() in reverse many-to-one managers.

[Django]

#34633: Add prefetch_related() cache invalidation for create() in reverse 
many-to-
one managers.
-+-
 Reporter:  Rob Percival |Owner:  Aman
 |  Pandey
 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:  1|UI/UX:  0
-+-
Changes (by Aman Pandey):

 * owner:  Rob Percival => Aman Pandey


-- 
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/0107018bf86ea0da-e21a1bff-9bd0-4f3a-9b12-d55f3a6c8d9e-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 > the HTTP server must send either `Content-Length` or `Transfer-Encoding:
 chunked`

 I do not think this is true, a third option is most likely to simply close
 the connection.

 > It’s less clear that the WSGI application should be responsible for
 sending it explicitly.

 It is explicitly clear that the WSGI application is not required to send
 this in PEP  (https://peps.python.org/pep-/#handling-the-content-
 length-header):

 > If the application does not supply a Content-Length header, a server or
 gateway may choose one of several approaches to handling it. The simplest
 of these is to close the client connection when the response is completed.

 So I would argue that this is a bug in uWSGI. This is also not the first
 WSGI incompatibility in uWGSI, for instance I fixed a rather annoying
 issue with close:
 https://github.com/unbit/uwsgi/commit/1746254fec076bd52e7682187041e82fafad5427

 > This is easy to reproduce without Django, so I don’t think we should
 feel obligated to avoid fixing this just to have a reproduction recipe.

 The thing is, if we fix this in Django just to workaround about a spec
 incompatibility in uWSGI (imo), then the next framework has to do the same
 and we just might hide a harder to fix bug. Fixing this in uWSGI would
 properly fix this for all frameworks.

-- 
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/0107018bf866bd39-4b823d85-d355-4dc4-ac04-b86ac7e4d4be-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Anders Kaseorg):

 A redirect response is allowed to have a body, so in order for keep-alive
 to work, the HTTP server must send either `Content-Length` or `Transfer-
 Encoding: chunked`. It’s less clear that the WSGI application should be
 responsible for sending it explicitly. I would have expected uWSGI to
 automatically add `Transfer-Encoding` if `Content-Length` is not provided,
 but evidently it doesn’t.

 This is easy to reproduce without Django, so I don’t think we should feel
 obligated to avoid fixing this just to have a reproduction recipe.

 {{{
 #!python3
 def application(environ, start_response):
 body = b"Hello, world!"
 start_response(
 "200 OK",
 [
 # ("Content-Length", str(len(body))),  # uncomment to fix
 ],
 )
 yield body
 }}}

-- 
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/0107018bf85a0f77-cff5bfd0-c79a-4987-a374-5236d2bf11cc-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 Case in point, it allowed me to identify a possible issue in my WSGI
 changes to hypercorn:
 https://github.com/pgjones/hypercorn/pull/155/files#r1402530266

-- 
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/0107018bf852affe-d9a0721e-c61d-4f3b-a120-470fe90b0c99-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Florian Apolloner):

 I am against fixing this if a Content-Length is not required on redirects
 (which I doubt it is). A bug like this is perfect to expose issues in WSGI
 implementations.

-- 
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/0107018bf84f2eb4-d2d7bc0d-04c5-4123-9cc9-ac9f71807f27-00%40eu-central-1.amazonses.com.

Re: [Django] #26827: "ModelState.fields cannot refer to a model class ... Use a string reference instead." when using custom model field derived from ManyToMany

[Django]

#26827: "ModelState.fields cannot refer to a model class ... Use a string 
reference
instead." when using custom model field derived from ManyToMany
-+-
 Reporter:  Rich Rauenzahn   |Owner:  Prashant
 Type:   |  Pandey
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Prashant Pandey):

 * owner:  (none) => Prashant Pandey
 * 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/0107018bf84b5212-82b55db2-f7eb-4f13-8402-6728c8a4a032-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  Anders
 |  Kaseorg
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anders Kaseorg):

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


Comment:

 The difference is that we stopped setting `Content-Length: 0` on these
 redirects. It is probably a uWSGI bug that removing `Content-Length`
 causes uWSGI to delay for `socket-timeout` seconds in this scenario;
 however, restoring it is easy and makes this symptom disappear.

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

-- 
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/0107018bf847ccfe-99495fb3-d32c-4331-a601-6d4605005b91-00%40eu-central-1.amazonses.com.

Re: [Django] #34978: Annotating through an aggregate with RawSQL() raises 1056 "Can't group on" on MySQL/MariaDB.

[Django]

#34978: Annotating through an aggregate with RawSQL() raises 1056 "Can't group 
on"
on MySQL/MariaDB.
-+-
 Reporter:  Matthew Somerville   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Matthew Somerville):

 > So in this case play.name is functionally dependant on play.id (as it's
 the primary key of play) so if you're using a version of MySQL supported
 on Django 4.2 we'd definitely like to learn more about it as it's
 unexpected.

 So it turns out the database is MariaDB (11.1.2), not MySQL, and MariaDB
 does not appear to include/have the functional dependency requirement that
 this is based on. I don't know if you'd like me to raise that as a
 separate ticket, if Django is supposed to support both entirely equally,
 but yes, it looks like the code will not work at all with MariaDB with
 ONLY_FULL_GROUP_BY turned on.

-- 
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/0107018bf83d248f-6f705cd5-9761-4f06-84f4-a9f119e2ea02-00%40eu-central-1.amazonses.com.

Re: [Django] #2259: Primary keys should be readonly by default in admin

[Django]

#2259: Primary keys should be readonly by default in admin
---+---
 Reporter:  ed@…   |Owner:  Prashant Pandey
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  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
---+---

Comment (by Prashant Pandey):

 Replying to [comment:28 Bouke Haarsmay]:
 Hi, I was following your solution and it gives same errors that you are
 getting(regression error for inline).
 I just need help in that area.
 Is there a way to access the context of the form inside the
 get_readonly_fields, means when we do:
 1. Create new object where primary key field will be in editing state.
 2. If we hit the change behaviour it should be readonly.

 we can add a condition in the get_readonly_fields function where it will
 send pk as a readonly if user wants to modify the object.

-- 
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/0107018bf816685c-39b6a4fb-9164-4091-8b3a-a34797e71295-00%40eu-central-1.amazonses.com.

Re: [Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
 Reporter:  Jeppe Fihl-Pearson   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  CommonMiddleware | Triage Stage:
  uWSGI  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Florian Apolloner):

 * cc: Florian Apolloner (added)


Comment:

 Can you compare tcpdumps between the two options, that might provide some
 indication of what is at fault.

-- 
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/0107018bf815f300-009be475-a7c1-4313-97cf-f6e51b16ead4-00%40eu-central-1.amazonses.com.

Re: [Django] #33700: APPEND_SLASH adds significant latency to all requests not ending in / (even if successful)

[Django]

#33700: APPEND_SLASH adds significant latency to all requests not ending in / 
(even
if successful)
-+-
 Reporter:  Anders Kaseorg   |Owner:  Anders
 Type:   |  Kaseorg
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  CommonMiddleware | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jeppe Fihl-Pearson):

 A minor heads up that I have identified the changes made for this ticket
 as the cause of a performance issue in how Django operates together with
 uWSGI, related to the `APPEND_SLASH` redirects: #34989.

-- 
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/0107018bf7d47d90-b1891496-cf39-4f37-ae70-d87c6f728fec-00%40eu-central-1.amazonses.com.

[Django] #34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's http11-socket

[Django]

#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-+-
   Reporter:  Tenzer |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP   |Version:  4.2
  handling   |   Keywords:  CommonMiddleware
   Severity:  Normal |  uWSGI
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 We upgraded from Django 4.1.13 to 4.2.7 this week, and as part of this, we
 noticed redirects for URLs that added a missing trailing slash took 4-5
 seconds. Before the upgrade, the redirects only took a fraction of a
 second to return.

 Debugging this, I've found out it's related to the change made for #33700.
 If I revert that change the delay goes away.

 I've also found out this requires a slightly specific setup. So far I've
 only seen it when using uWSGI as the application server using the
 `http11-socket` option. I am not able to reproduce the issue when using
 `http-socket` for configuring the listening socket.

 I have adapted the reproduction case from #33700 to show this issue. It
 can be found at https://github.com/Tenzer/django-slow-redirect. When
 making a request against the `http-socket` port, it returns immediately:
 {{{
 % time curl -si http://127.0.0.1:8010/url
 HTTP/1.1 301 Moved Permanently
 Content-Type: text/html; charset=utf-8
 Location: /url/

 curl -si http://127.0.0.1:8010/url  0.01s user 0.01s system 65% cpu 0.033
 total
 }}}
 but when I make a request against the `http11-socket` port, it instead
 takes at least 4 seconds extra:
 {{{
 % time curl -si http://127.0.0.1:8011/url
 HTTP/1.1 301 Moved Permanently
 Content-Type: text/html; charset=utf-8
 Location: /url/

 curl -si http://127.0.0.1:8011/url  0.01s user 0.01s system 0% cpu 4.026
 total
 }}}

 I am assuming this might be hitting a timeout somewhere but I can't work
 out where that might be or how the changes in
 https://github.com/django/django/pull/15689 might have caused it.

 We have for now had to switch to using the `http-socket` option in uWSGI,
 but it would be ideal if the `http11-socket` option also would work, as
 that is required for uWSGI to support keep-alive.

-- 
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/0107018bf7ac2845-34f07ad1-a666-4735-82b0-30e756e1c841-00%40eu-central-1.amazonses.com.

Re: [Django] #34988: Makemigrations shouldn't prompt for default values for non-nullable fields of other apps.

[Django]

#34988: Makemigrations shouldn't prompt for default values for non-nullable 
fields
of other apps.
+
 Reporter:  Sarah Boyce |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Migrations  |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  makemigrations  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Mariusz Felisiak):

 Follow up to #22791.

-- 
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/0107018bf782e09a-7c44754c-2df8-4bfa-a3d5-674db485391a-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * cc: Peter Thomassen (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/0107018bf7729400-020a84f4-1172-469f-a6fd-43fe5027900a-00%40eu-central-1.amazonses.com.

Re: [Django] #34988: Makemigrations shouldn't prompt for default values for non-nullable fields of other apps.

[Django]

#34988: Makemigrations shouldn't prompt for default values for non-nullable 
fields
of other apps.
+
 Reporter:  Sarah Boyce |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Migrations  |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  makemigrations  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by David Sanders):

 Just thinking about whether this is feasible to do: The autodetector is
 documented as being designed to run on entire projects but I wonder if
 it's possible to delay prompting the questioner for various things it
 requests until after `_trim_changes()` is called.

-- 
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/0107018bf748b821-8e708779-1d8d-4186-914c-83366dabd271-00%40eu-central-1.amazonses.com.

Re: [Django] #34988: Makemigrations shouldn't prompt for default values for non-nullable fields of other apps.

[Django]

#34988: Makemigrations shouldn't prompt for default values for non-nullable 
fields
of other apps.
+
 Reporter:  Sarah Boyce |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Migrations  |  Version:  dev
 Severity:  Normal  |   Resolution:
 Keywords:  makemigrations  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by David Sanders):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks again for another report 

 Confirmed this is indeed happening for apps with mutually independent
 migrations ✓

 What's more is that if you run `makemigrations` a second time it asks for
 a default but then reports "No changes detected in app "

 {{{
 django-sample % dj makemigrations ticket_34988_app_1
 It is impossible to add a non-nullable field 'foo' to app2 without
 specifying a default. This is because the database needs something to
 populate existing rows.
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows with a
 null value for this column)
  2) Quit and manually define a default value in models.py.
 Select an option: 1
 Please enter the default value as valid Python.
 The datetime and django.utils.timezone modules are available, so it is
 possible to provide e.g. timezone.now as a value.
 Type 'exit' to exit this prompt
 >>> 1
 It is impossible to add a non-nullable field 'bar' to app1 without
 specifying a default. This is because the database needs something to
 populate existing rows.
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows with a
 null value for this column)
  2) Quit and manually define a default value in models.py.
 Select an option: 1
 Please enter the default value as valid Python.
 The datetime and django.utils.timezone modules are available, so it is
 possible to provide e.g. timezone.now as a value.
 Type 'exit' to exit this prompt
 >>> 1
 Migrations for 'ticket_34988_app_1':
   ticket_34988_app_1/migrations/0002_app2_foo.py
 - Add field foo to app2
 django-sample % dj makemigrations ticket_34988_app_1
 It is impossible to add a non-nullable field 'bar' to app1 without
 specifying a default. This is because the database needs something to
 populate existing rows.
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows with a
 null value for this column)
  2) Quit and manually define a default value in models.py.
 Select an option: 1
 Please enter the default value as valid Python.
 The datetime and django.utils.timezone modules are available, so it is
 possible to provide e.g. timezone.now as a value.
 Type 'exit' to exit this prompt
 >>> 1
 No changes detected in app 'ticket_34988_app_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/0107018bf72b0efd-c7287454-a08d-4b54-b682-3d1e9596b6a7-00%40eu-central-1.amazonses.com.

[Django] #34988: Makemigrations shouldn't prompt for default values for non-nullable fields of other apps.

[Django]

#34988: Makemigrations shouldn't prompt for default values for non-nullable 
fields
of other apps.
-+
   Reporter:  Sarah Boyce|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Migrations |Version:  dev
   Severity:  Normal |   Keywords:  makemigrations
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Have more than one app (app_1 and app_2). In app_1 have a model that has
 it's migrations applied then add a field that doesn't have a default and
 is not nullable (do not run makemigrations).
 Then add a new model (or anything that would require a migration) to
 app_2.
 Run `manage.py makemigrations app_2`

 You get prompted for every app that has unapplied migrations missing
 defaults even though you're running migrations for a different app.
 I would expect it not to care, as you can input temporary defaults to all
 these other apps and it doesn't do anything with them.

 I think this might be a test case:

 {{{
 diff --git a/tests/migrations/test_commands.py
 b/tests/migrations/test_commands.py
 index a9c1cdf893..518ebef872 100644
 --- a/tests/migrations/test_commands.py
 +++ b/tests/migrations/test_commands.py
 @@ -1979,6 +1979,39 @@ class MakeMigrationsTests(MigrationTestBase):
  self.assertIn("Remove field silly_field from sillymodel",
 out.getvalue())
  self.assertIn("Add field silly_rename to sillymodel",
 out.getvalue())

 +@override_settings(
 +INSTALLED_APPS=[
 +"migrations",
 +"migrations.migrations_test_apps.migrated_app",
 +]
 +)
 +def
 
test_makemigrations_interactive_not_null_addition_multiple_apps_single_call(self):
 +class Author(models.Model):
 +silly_author_field = models.BooleanField(null=False)
 +
 +class Meta:
 +app_label = "migrations"
 +
 +class NewModel1(models.Model):
 +class Meta:
 +app_label = "migrated_app"
 +
 +input_msg = (
 +"It is impossible to add a non-nullable field
 'silly_author_field' to "
 +"author without specifying a default. This is because the "
 +"database needs something to populate existing rows.\n"
 +"Please select a fix:\n"
 +" 1) Provide a one-off default now (will be set on all
 existing "
 +"rows with a null value for this column)\n"
 +" 2) Quit and manually define a default value in models.py."
 +)
 +with
 self.temporary_migration_module(module="migrations.test_migrations"):
 +with mock.patch("builtins.input", return_value="1"):
 +with captured_stdout() as out:
 +call_command("makemigrations", "migrated_app",
 interactive=True)
 +output = out.getvalue()
 +self.assertNotIn(input_msg, output)
 +
  @mock.patch("builtins.input", return_value="Y")
  def test_makemigrations_model_rename_interactive(self, mock_input):
  class RenamedModel(models.Model):
 }}}

-- 
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/0107018bf7179a9f-683b34e4-dbf4-4d59-86fa-1f757d8d4c19-00%40eu-central-1.amazonses.com.

Re: [Django] #34985: Migrations raise AppRegistryNotReady when GeneratedField references incorrect fields.

[Django]

#34985: Migrations raise AppRegistryNotReady when GeneratedField references
incorrect fields.
-+-
 Reporter:  Paolo Melchiorre |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"48eebdc63caca18fef90ce49dd5473fd338ebe94" 48eebdc]:
 {{{
 #!CommitTicketReference repository=""
 revision="48eebdc63caca18fef90ce49dd5473fd338ebe94"
 [5.0.x] Fixed #34985 -- Fixed GeneratedFields.contribute_to_class() crash
 when apps are not populated.

 Thanks Paolo Melchiorre for the report.

 Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.
 Backport of 101a85a5a06585ba16ecb25860146d034a8a55ec 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/0107018bf7150842-0b65e061-a319-48c0-9aff-6839e38bb31b-00%40eu-central-1.amazonses.com.

Re: [Django] #34985: Migrations raise AppRegistryNotReady when GeneratedField references incorrect fields.

[Django]

#34985: Migrations raise AppRegistryNotReady when GeneratedField references
incorrect fields.
-+-
 Reporter:  Paolo Melchiorre |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"101a85a5a06585ba16ecb25860146d034a8a55ec" 101a85a]:
 {{{
 #!CommitTicketReference repository=""
 revision="101a85a5a06585ba16ecb25860146d034a8a55ec"
 Fixed #34985 -- Fixed GeneratedFields.contribute_to_class() crash when
 apps are not populated.

 Thanks Paolo Melchiorre for the report.

 Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.
 }}}

-- 
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/0107018bf70ce723-e2ce1a43-35b2-47db-b1b0-83b3546367fc-00%40eu-central-1.amazonses.com.

Re: [Django] #34984: Adding a field with default crashes for models with GeneratedField on SQLite.

[Django]

#34984: Adding a field with default crashes for models with GeneratedField on
SQLite.
-+-
 Reporter:  Sarah Boyce  |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sqlite   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0c6ca522263b0f5c4075b3634d7e5507d9528b52" 0c6ca522]:
 {{{
 #!CommitTicketReference repository=""
 revision="0c6ca522263b0f5c4075b3634d7e5507d9528b52"
 [5.0.x] Fixed #34984 -- Skipped GeneratedFields when remaking tables on
 SQLite.

 Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.t

 Co-authored-by: Mariusz Felisiak 
 Co-authored-by: David Sanders 

 Backport of 828082dad954e87d09a99b53424e6faa1860ccc7 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/0107018bf7005464-6829ff22-d971-4291-813e-35dd5de08a1e-00%40eu-central-1.amazonses.com.

Re: [Django] #34984: Adding a field with default crashes for models with GeneratedField on SQLite.

[Django]

#34984: Adding a field with default crashes for models with GeneratedField on
SQLite.
-+-
 Reporter:  Sarah Boyce  |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sqlite   | 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:"828082dad954e87d09a99b53424e6faa1860ccc7" 828082da]:
 {{{
 #!CommitTicketReference repository=""
 revision="828082dad954e87d09a99b53424e6faa1860ccc7"
 Fixed #34984 -- Skipped GeneratedFields when remaking tables on SQLite.

 Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.t

 Co-authored-by: Mariusz Felisiak 
 Co-authored-by: David Sanders 
 }}}

-- 
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/0107018bf7000a2a-6087f5b4-4d3b-4f21-883a-65cbe942972e-00%40eu-central-1.amazonses.com.

Re: [Django] #34984: Adding a field with default crashes for models with GeneratedField on SQLite.

[Django]

#34984: Adding a field with default crashes for models with GeneratedField on
SQLite.
-+-
 Reporter:  Sarah Boyce  |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  sqlite   | 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


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bf6cbc292-99955b36-9489-4ad4-b9fe-b1d19d662a67-00%40eu-central-1.amazonses.com.

Re: [Django] #34985: Migrations raise AppRegistryNotReady when GeneratedField references incorrect fields.

[Django]

#34985: Migrations raise AppRegistryNotReady when GeneratedField references
incorrect fields.
-+-
 Reporter:  Paolo Melchiorre |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  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/0107018bf6cb51f3-5ee6f75a-424a-4e58-b25e-19acae2fe8cc-00%40eu-central-1.amazonses.com.

Re: [Django] #34987: "Expression contains mixed types" exception when performing window function on query that also has aggregates.

[Django]

#34987: "Expression contains mixed types" exception when performing window 
function
on query that also has aggregates.
-+-
 Reporter:  ElRoberto538 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  Expression, Window,  | Triage Stage:  Accepted
  aggregate, annotation, partition   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * severity:  Normal => Release blocker


Comment:

 Settings as release blocker since the bisected revision was released in
 4.2a1

-- 
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/0107018bf6ca76d1-881a7781-83b3-4944-877e-c648032d2834-00%40eu-central-1.amazonses.com.

Re: [Django] #34985: Migrations raise AppRegistryNotReady when GeneratedField references incorrect fields.

[Django]

#34985: Migrations raise AppRegistryNotReady when GeneratedField references
incorrect fields.
-+-
 Reporter:  Paolo Melchiorre |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bf66fd7a4-814512d3-a689-4ca6-8f88-2639a12a0cdc-00%40eu-central-1.amazonses.com.

Re: [Django] #34984: Adding a field with default crashes for models with GeneratedField on SQLite.

[Django]

#34984: Adding a field with default crashes for models with GeneratedField on
SQLite.
-+-
 Reporter:  Sarah Boyce  |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * has_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/0107018bf6453b1f-24a79c9f-fd37-461e-9bb1-ac64fd4e57ea-00%40eu-central-1.amazonses.com.

Re: [Django] #34986: Fix up support for PyPy 3.10

[Django]

#34986: Fix up support for PyPy 3.10
--+-
 Reporter:  Nick Pope |Owner:  Nick Pope
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:  pypy  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by GitHub ):

 In [changeset:"0d407bcce5449d839fab138baeb9220f6df6bd6d" 0d407bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d407bcce5449d839fab138baeb9220f6df6bd6d"
 Refs #34986 -- Installed libmemcached-dev in PyPy 3.10 daily builds.
 }}}

-- 
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/0107018bf6415a39-00e49242-0d49-427c-aac7-acf7ff08cb74-00%40eu-central-1.amazonses.com.

Re: [Django] #34900: Python 3.13 compatibility.

[Django]

#34900: Python 3.13 compatibility.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"584fc49ac48acb16051c3153d01bb23aa8599a52" 584fc49]:
 {{{
 #!CommitTicketReference repository=""
 revision="584fc49ac48acb16051c3153d01bb23aa8599a52"
 Refs #34900 -- Skipped Selenium requirement on daily builds for Python
 3.13.

 Selenium required trio and trio required cffi on Windows.
 }}}

-- 
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/0107018bf63a39da-cae41d59-f9ae-4136-aa75-cc3746f00aee-00%40eu-central-1.amazonses.com.