Re: [Django] #33050: QuerySet.count() on combined queries with select_related() crashes on MySQL.

[Django]

#33050: QuerySet.count() on combined queries with select_related() crashes on
MySQL.
-+-
 Reporter:  Sunkyue  |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  orm, count, union,   | Triage Stage:  Accepted
  select_related mysql   |
Has patch:  0|  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:

 Replying to [comment:11 Simon Charette]:
 > I haven't tried it out but I wouldn't be surprised if this was fixed by
 70499b25c708557fb9ee2264686cd172f4b2354e (#34123) as it ensures that all
 combined queries have non-colliding aliases.

 Good catch! I submitted [https://github.com/django/django/pull/16323 PR]
 with tests.

 Fixed in 70499b25c708557fb9ee2264686cd172f4b2354e.

-- 
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/01070184a35dd9a7-91539358-2787-41cd-b1a7-23b635ac3b60-00%40eu-central-1.amazonses.com.

Re: [Django] #33403: Annotate results change when filtering *after* the annotate

[Django]

#33403: Annotate results change when filtering *after* the annotate
-+-
 Reporter:  karyon   |Owner:  Abhinav
 Type:   |  Yadav
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 Mariusz Felisiak):

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


Comment:

 Replying to [comment:11 Simon Charette]:
 > FWIW this seems highly related if not a duplicate of #15049.

 Agreed, let's close it as a duplicate of #15049.

-- 
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/01070184a34789c3-1852c214-ea6a-483b-a7df-f26cf33eff88-00%40eu-central-1.amazonses.com.

Re: [Django] #32813: Display development server address after server bind

[Django]

#32813: Display development server address after server bind
-+-
 Reporter:  fmwviormv|Owner:  Dhanush
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  development server,  | Triage Stage:  Accepted
  automatic port |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Abhijeet Pal):

 Hi, sorry.

 But I was waiting for some comments on it to move forward to closing the
 ticket on my PR.

 I missed Carlton's notification of
 {{{
 Patch needs improvement: set
 }}}
 Never mind I wish you luck.

-- 
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/01070184a2d45449-81ce2d9e-a8c8-48ee-935e-daf08bdd530f-00%40eu-central-1.amazonses.com.

Re: [Django] #15049: Using annotation before and after filter gives wrong results

[Django]

#15049: Using annotation before and after filter gives wrong results
-+-
 Reporter:  Alex Gaynor  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > I say we don't fix this issue. Instead we could add an explicit way to
 introduce joins.

 fwiw this `add_relation` somewhat exists today though
 `QuerySet.alias(alias=FilteredRelation("relation"))`

-- 
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/01070184a2d40d45-1109a0af-f0b8-4c0b-a14f-fb94da7fffec-00%40eu-central-1.amazonses.com.

Re: [Django] #33403: Annotate results change when filtering *after* the annotate

[Django]

#33403: Annotate results change when filtering *after* the annotate
-+-
 Reporter:  karyon   |Owner:  Abhinav
 Type:   |  Yadav
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 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
-+-

Comment (by Simon Charette):

 FWIW this seems highly related to #15049.

-- 
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/01070184a2d28a9e-4b79eda4-b4fd-4569-9bdd-b9ad5f8ffbd4-00%40eu-central-1.amazonses.com.

Re: [Django] #33050: QuerySet.count() on combined queries with select_related() crashes on MySQL.

[Django]

#33050: QuerySet.count() on combined queries with select_related() crashes on
MySQL.
-+-
 Reporter:  Sunkyue  |Owner:  Jordan
 |  Bae
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, count, union,   | Triage Stage:  Accepted
  select_related mysql   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I haven't tried it out but I wouldn't be surprised if this was fixed by
 70499b25c708557fb9ee2264686cd172f4b2354e (#34123) as it ensures that all
 combined queries have non-colliding aliases.

-- 
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/01070184a2cdb970-57f765cb-fe48-4afc-a2e0-3792c816eefe-00%40eu-central-1.amazonses.com.

Re: [Django] #31679: Django subtly produces incorrect query when the same keyword appears in both aggregate() and annotate()

[Django]

#31679: Django subtly produces incorrect query when the same keyword appears in
both aggregate() and annotate()
-+-
 Reporter:  StefanosChaliasos|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 Simon Charette):

 * owner:  (none) => Simon Charette
 * 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/01070184a2bb78ea-74b3bd92-fd11-4095-a4a2-481eac313821-00%40eu-central-1.amazonses.com.

Re: [Django] #31679: Django subtly produces incorrect query when the same keyword appears in both aggregate() and annotate()

[Django]

#31679: Django subtly produces incorrect query when the same keyword appears in
both aggregate() and annotate()
-+-
 Reporter:  StefanosChaliasos|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 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 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/01070184a29ecb43-c7c69e38-dc70-4866-b6f2-22ff52771804-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code

[Django]

#34173: SessionMiddleware support 503 status code
-+-
 Reporter:  SessionIssue |Owner:  Abhinav
 Type:   |  Yadav
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sessions |  Version:  4.1
 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 Abhinav Yadav):

 * owner:  nobody => Abhinav Yadav
 * 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/01070184a295d496-fae90e04-2b20-4dea-8bbc-3788b6bbe8d6-00%40eu-central-1.amazonses.com.

Re: [Django] #34176: Annotation's original field-name can clash with result field name over aggregation

[Django]

#34176: Annotation's original field-name can clash with result field name over
aggregation
-+-
 Reporter:  Shai Berger  |Owner:  Simon
 |  Charette
 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 Simon Charette):

 * has_patch:  0 => 1


Comment:

 I didn't know that

 {{{#!python
 Book.objects.values('isbn').annotate(
 name=F('publisher__name'),
 )
 }}}

 was allowed but


 {{{#!python
 > Book.objects.values('isbn', name=F('publisher__name'))
 ValueError: The annotation 'name' conflicts with a field on the model.
 }}}

 isn't which seems like a bug in #25871?

 Anyway, I submitted [https://github.com/django/django/pull/16321 this MR]
 for review which avoids a complex refactor of `get_select` that would have
 necessitated reference repointing.

 This means that group by reference will be disabled for annotations that
 conflict will a selected column name but I think that's an acceptable
 compromise given it should only have an incidence for with complex
 annotations that can't be collapsed assigned with ambiguous names. This a
 compromise we already took in #31377 as well and has a workaround for
 users that must get the group be reference; use an annotation name that
 doesn't conflict with an already selected column name.

-- 
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/01070184a206413b-66e45b78-690e-498d-8ae6-61d5acb0cc64-00%40eu-central-1.amazonses.com.

Re: [Django] #34151: Adding explicit primary key with different type doesn't update related ManyToManyFields.

[Django]

#34151: Adding explicit primary key with different type doesn't update related
ManyToManyFields.
-+-
 Reporter:  STANISLAV LEPEKHOV   |Owner:  Bhuvnesh
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  migrations pk uuid   | Triage Stage:  Accepted
  relation   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Bhuvnesh):

 * owner:  nobody => Bhuvnesh
 * 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/01070184a0e74a0a-d93a5d5b-2b97-4b50-ab7a-ef468bd12d22-00%40eu-central-1.amazonses.com.

Re: [Django] #34179: Django F expression not working as expected on MariaDB 10.5.13

[Django]

#34179: Django F expression not working as expected on MariaDB 10.5.13
-+-
 Reporter:  Gerben Morsink   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  mysql, mariadb   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Hi, thanks for this report, however everything works for me with MariaDB
 10.5.13 (I checked tests added in
 779e615e362108862f1681f965ee9e4f1d0ae6d2).

-- 
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/01070184a0cb3deb-f2671ee2-0d5c-497b-9fba-cfec5d51e149-00%40eu-central-1.amazonses.com.

Re: [Django] #34171: QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields.

[Django]

#34171: QuerySet.bulk_create() crashes on mixed case columns in
unique_fields/update_fields.
-+-
 Reporter:  Joshua Brooks|Owner:  Bhuvnesh
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"170322451acc18ff3311c68db1b9b1d3f7cb7913" 1703224]:
 {{{
 #!CommitTicketReference repository=""
 revision="170322451acc18ff3311c68db1b9b1d3f7cb7913"
 [4.1.x] Fixed #34171 -- Fixed QuerySet.bulk_create() on fields with
 db_column in unique_fields/update_fields.

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.

 Thanks Joshua Brooks for the report.

 Backport of 4035bab56f2862a25cd7bfba41a84e58672cb1cc 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/01070184a0bada4b-74dfb396-877b-4024-a1ff-fdcc768e1781-00%40eu-central-1.amazonses.com.

Re: [Django] #34171: QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields.

[Django]

#34171: QuerySet.bulk_create() crashes on mixed case columns in
unique_fields/update_fields.
-+-
 Reporter:  Joshua Brooks|Owner:  Bhuvnesh
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"4035bab56f2862a25cd7bfba41a84e58672cb1cc" 4035bab5]:
 {{{
 #!CommitTicketReference repository=""
 revision="4035bab56f2862a25cd7bfba41a84e58672cb1cc"
 Fixed #34171 -- Fixed QuerySet.bulk_create() on fields with db_column in
 unique_fields/update_fields.

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.

 Thanks Joshua Brooks 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/01070184a0bac2ff-27a64f0e-514e-4bdd-b512-8974ed9c3d5c-00%40eu-central-1.amazonses.com.

Re: [Django] #34174: async process_exception being called as sync from async view/middleware

[Django]

#34174: async process_exception being called as sync from async view/middleware
-+-
 Reporter:  Gabriel Rado |Owner:  Gabriel
 Type:   |  Rado
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  middleware async | Triage Stage:  Accepted
  process_exception  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Gabriel Rado):

 * owner:  nobody => Gabriel Rado
 * 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/01070184a08253b2-acb2fd64-aa0b-4b63-829d-0f34356360b6-00%40eu-central-1.amazonses.com.

Re: [Django] #32813: Display development server address after server bind

[Django]

#32813: Display development server address after server bind
-+-
 Reporter:  fmwviormv|Owner:  Dhanush
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  development server,  | Triage Stage:  Accepted
  automatic port |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Dhanush):

 * owner:  Abhijeet Pal => Dhanush
 * needs_better_patch:  1 => 0


Comment:

 PR https://github.com/django/django/pull/16319

-- 
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/010701849ff6beee-e13a4fee-3c4c-41ae-b2d3-818e85de70a9-00%40eu-central-1.amazonses.com.

[Django] #34179: Django F expression not working as expected on MariaDB 10.5.13

[Django]

#34179: Django F expression not working as expected on MariaDB 10.5.13
-+-
   Reporter:  Gerben |  Owner:  nobody
  Morsink|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  mysql, mariadb
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 My hosting updated the server from MySQL 5.7 to MariaDB 10.5.13. Although
 all data was preserved correctly, I found out the ordering of some Model
 instances stopped working.

 After spending multiple days on the issue I have found that the issue
 comes from the fix that is created here:
 https://code.djangoproject.com/ticket/31573

 Somehow with (this version of?) MariaDB when you add the order before the
 update, everything will end up with the same order, instead of just adding
 one to the current order.

 In code:


 if qs_to_increase orders are [2, 3]
 {{{
 qs_to_increase = qs_to_increase.order_by('-order').update(
 order=F('order') + 1)
 }}}
 Ends up with qs_to_increse order [4,4]


 {{{
 qs_to_increase = qs_to_increase.update(
 order=F('order') + 1)
 }}}
 works and gives (correctly) [3,4]

 Although I think not many people will be affected (the extra .order_by was
 only necessary for MySQL), it is strange that the update to MariaDB
 10.5.13 results in a data error. Also, related MySQL versions (8.0?) might
 also be affected.

-- 
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/010701849ff5fdd3-be0a9a1e-debd-4f1f-a47b-35ac84901b1e-00%40eu-central-1.amazonses.com.

Re: [Django] #34171: QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields.

[Django]

#34171: QuerySet.bulk_create() crashes on mixed case columns in
unique_fields/update_fields.
-+-
 Reporter:  Joshua Brooks|Owner:  Bhuvnesh
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 [https://github.com/django/django/pull/16315 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/010701849f9b5556-cc2cacac-e686-4a72-b8b0-beeb33c5cd14-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code

[Django]

#34173: SessionMiddleware support 503 status code
--+
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  Version:  4.1
 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 Carlton Gibson):

 * easy:  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/010701849f94ed4a-659c921c-8d30-4b31-8f57-c3377d1c6ccf-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code

[Django]

#34173: SessionMiddleware support 503 status code
--+
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.sessions  |  Version:  4.1
 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 Carlton Gibson):

 * type:  New feature => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Happy to look at a patch (with tests) adjusting the check to `if
 response.status_code >= 500:`

-- 
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/010701849f943606-626e5c95-719b-43e8-bf67-5bd1f98956e6-00%40eu-central-1.amazonses.com.

Re: [Django] #34176: Annotation's original field-name can clash with result field name over aggregation

[Django]

#34176: Annotation's original field-name can clash with result field name over
aggregation
-+-
 Reporter:  Shai Berger  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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
-+-
Changes (by Simon Charette):

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


Comment:

 Thanks for the report Shai.

 I stumbled upon something similar in #34123 when trying to have
 `get_select` use the `values` aliases instead of `colN` ones for aesthetic
 reasons.

 Changes are required in `SQLCompiler.get_select` that are similar to
 
[https://github.com/django/django/blob/7d5329852f19c6ae78c6f6f3d3e41835377bf295/django/db/models/sql/query.py#L2221-L2245
 the ones] in `sql.Query.set_group_by(allow_aliases=True)`.

-- 
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/010701849f90b06b-9376604b-f00c-4040-b55a-0acff48e3918-00%40eu-central-1.amazonses.com.

Re: [Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3b0a8ea2993a2b011ad57304b3f978947adb5981" 3b0a8ea]:
 {{{
 #!CommitTicketReference repository=""
 revision="3b0a8ea2993a2b011ad57304b3f978947adb5981"
 [4.1.x] Fixed #34177 -- Fixed QuerySet.bulk_create() crash on "pk" in
 unique_fields.

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.
 Backport of 7d5329852f19c6ae78c6f6f3d3e41835377bf295 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/010701849f85c20d-bb941616-58f3-49bf-a9aa-23c1823bf0d7-00%40eu-central-1.amazonses.com.

Re: [Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"7d5329852f19c6ae78c6f6f3d3e41835377bf295" 7d53298]:
 {{{
 #!CommitTicketReference repository=""
 revision="7d5329852f19c6ae78c6f6f3d3e41835377bf295"
 Fixed #34177 -- Fixed QuerySet.bulk_create() crash on "pk" in
 unique_fields.

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.
 }}}

-- 
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/010701849f855678-e24874e4-039c-42ae-929b-e19e8fad4a32-00%40eu-central-1.amazonses.com.

Re: [Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => 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/010701849f7ffba3-effb219a-e35d-4d89-b751-7588ce73f659-00%40eu-central-1.amazonses.com.

Re: [Django] #34178: Prefetching a foreign key on GenericForeignKey results in incorrect queryset being selected

[Django]

#34178: Prefetching a foreign key on GenericForeignKey results in incorrect
queryset being selected
-+-
 Reporter:  Rohan Nahata |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  GenericForeignKey,   | Triage Stage:
  prefetch_related   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * type:  Bug => New feature
 * resolution:   => duplicate


Comment:

 `QuerySet.prefetch_related()` works with `GenericForeignKey`, however it
 is only supported if the query is restricted to one `ContentType` (see
 `prefetch_related()`
 [https://docs.djangoproject.com/en/stable/ref/models/querysets/#prefetch-
 related docs]).

 Duplicate of #33651.

-- 
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/010701849f7bb186-6c2477f1-7e3e-4e68-9996-6326339b1263-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions.

[Django]

#34165: migrate management command does not respect database parameter when 
adding
Permissions.
--+
 Reporter:  Vasanth   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  4.1
 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 Vasanth):

 After diving a bit deeper it turned out that the issue was with one of the
 libraries in my project which was not adapted for multi-DB. I've made a PR
 with changes on the django-admin-interface which resolved my issue.

-- 
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/010701849f756017-c0458caf-bbf7-4fae-a780-31fae8c7ffb6-00%40eu-central-1.amazonses.com.

Re: [Django] #34095: Form controls in admin should use heights in relative units

[Django]

#34095: Form controls in admin should use heights in relative units
---+---
 Reporter:  Thibaud Colas  |Owner:  SwastikTripathi
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  4.1
 Severity:  Normal |   Resolution:
 Keywords:  accessibility  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+---
Changes (by SwastikTripathi):

 * owner:  jer => SwastikTripathi


-- 
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/010701849f722cda-a7a32a7e-3d87-4295-9599-aeca4a2d5d63-00%40eu-central-1.amazonses.com.

Re: [Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Mariusz Felisiak:

Old description:

> `QuerySet.bulk_create()` crashes on `"pk"` in `unique_fields` which
> should be allowed.
>
> Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.

New description:

 `QuerySet.bulk_create()` crashes on `"pk"` in `unique_fields` which should
 be allowed.
 {{{
   File "/django/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)
 django.db.utils.ProgrammingError: column "pk" does not exist
 LINE 1: ...S (3127, 3, 3, 'c'), (3128, 4, 4, 'd') ON CONFLICT("pk") DO ...
 }}}

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.

--

-- 
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/010701849f52dba8-4bc5b7dc-f946-43d8-bdc2-9f68e5591eac-00%40eu-central-1.amazonses.com.

Re: [Django] #34176: Annotation's original field-name can clash with result field name over aggregation

[Django]

#34176: Annotation's original field-name can clash with result field name over
aggregation
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (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
-+-
Changes (by Mariusz Felisiak):

 * version:  4.1 => dev
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report!

 Reproduced at 744a1af7f943106e30d538e6ace55c2c66ccd791.

-- 
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/010701849f49d686-ced8e93f-291f-4015-9269-5cb8e37d2cde-00%40eu-central-1.amazonses.com.

Re: [Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | 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):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/16317 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/010701849f3d7001-80959664-4d94-43d0-99c2-240ba2e0fc3d-00%40eu-central-1.amazonses.com.

Re: [Django] #34178: Prefetching a foreign key on GenericForeignKey results in incorrect queryset being selected

[Django]

#34178: Prefetching a foreign key on GenericForeignKey results in incorrect
queryset being selected
-+-
 Reporter:  Rohan Nahata |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericForeignKey,   | Triage Stage:
  prefetch_related   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Rohan Nahata:

Old description:

> These are the models that I created to test my hypothesis. .
> {{{
> class Foreign(models.Model):
> value = models.CharField(max_length=20)
>
> class OtherForeign(models.Model):
> value = models.CharField(max_length=20)
>
> class A(models.Model):
> f = models.ForeignKey(Foreign, on_delete=models.PROTECT)
>
> class B(models.Model):
> f = models.ForeignKey(OtherForeign, on_delete=models.PROTECT)
>
> class X(models.Model):
> ct = models.ForeignKey(ContentType, on_delete=models.PROTECT)
> object_id = models.IntegerField()
> object = GenericForeignKey(ct_field='ct', fk_field='object_id')
> }}}
>
> The tables were populated with this sample data.
> {{{
> Foreign
>
> id|value
> 1|A1
> 2|A2
> 3|A3
> 4|A4
> 5|A5
> 6|A6
> 7|A7
> 8|A8
> 9|A9
> 10|A10
>

> Other Foreign
>
> id|value
> 1|B1
> 2|B2
> 3|B3
> 4|B4
> 5|B5
> 6|B6
> 7|B7
> 8|B8
> 9|B9
> 10|B10
>
> A
>
> id|f_id
> 1|1
> 2|2
> 3|3
> 4|4
> 5|5
> 6|6
> 7|7
> 8|8
> 9|9
> 10|10
>
> B
>
> id|f_id
> 1|1
> 2|2
> 3|3
> 4|4
> 5|5
> 6|6
> 7|7
> 8|8
> 9|9
> 10|10
>
> X
> id|object_id|ct_id
> 1|1|11
> 2|2|11
> 3|3|11
> 4|4|11
> 5|5|11
> 6|6|11
> 7|7|11
> 8|8|11
> 9|9|11
> 10|10|11
> 11|1|10
> 12|2|10
> 13|3|10
> 14|4|10
> 15|5|10
> 16|6|10
> 17|7|10
> 18|8|10
> 19|9|10
> 20|10|10
>
> }}}
>
> Based on this data :
>
> {{{
> ->> xx = X.objects.prefetch_related('object').all().order_by('id')
> ->> xx[0].object.f.value
> 'A1'
> ->> xx[10].object.f.value
> 'B1'
> }}}
> This behaviour is correct.
>
> However, when we chain another prefetch to the same,
> {{{
> ->> xx = X.objects.prefetch_related('object',
> 'object__f').all().order_by('id')
> ->> xx[0].object.f.value
> 'A1'
> ->> xx[10].object.f.value
> 'A1'
> }}}
> Here, {{{xx[10].object}}} returns the correct object, however, when
> {{{xx[10].object.f}}} is evaluated it refers to model A instead of model
> B. This leads me to believe that there is some sort of faulty caching
> going on in the background that leads to model A being used.

New description:

 These are the models that I created to test my hypothesis. .
 {{{
 class Foreign(models.Model):
 value = models.CharField(max_length=20)

 class OtherForeign(models.Model):
 value = models.CharField(max_length=20)

 class A(models.Model):
 f = models.ForeignKey(Foreign, on_delete=models.PROTECT)

 class B(models.Model):
 f = models.ForeignKey(OtherForeign, on_delete=models.PROTECT)

 class X(models.Model):
 ct = models.ForeignKey(ContentType, on_delete=models.PROTECT)
 object_id = models.IntegerField()
 object = GenericForeignKey(ct_field='ct', fk_field='object_id')
 }}}

 The tables were populated with this sample data.
 {{{
 Foreign

 id|value
 1|A1
 2|A2
 3|A3
 4|A4
 5|A5
 6|A6
 7|A7
 8|A8
 9|A9
 10|A10


 Other Foreign

 id|value
 1|B1
 2|B2
 3|B3
 4|B4
 5|B5
 6|B6
 7|B7
 8|B8
 9|B9
 10|B10

 A

 id|f_id
 1|1
 2|2
 3|3
 4|4
 5|5
 6|6
 7|7
 8|8
 9|9
 10|10

 B

 id|f_id
 1|1
 2|2
 3|3
 4|4
 5|5
 6|6
 7|7
 8|8
 9|9
 10|10

 X
 id|object_id|ct_id
 1|1|11
 2|2|11
 3|3|11
 4|4|11
 5|5|11
 6|6|11
 7|7|11
 8|8|11
 9|9|11
 10|10|11
 11|1|10
 12|2|10
 13|3|10
 14|4|10
 15|5|10
 16|6|10
 17|7|10
 18|8|10
 19|9|10
 20|10|10

 }}}

 Based on this data :

 {{{
 ->> xx = X.objects.prefetch_related('object').all().order_by('id')
 ->> xx[0].object.f.value
 'A1'
 ->> xx[10].object.f.value
 'B1'
 }}}
 This behaviour is correct.

 However, when we chain another prefetch to the same,
 {{{
 ->> xx = X.objects.prefetch_related('object',
 'object__f').all().order_by('id')
 ->> xx[0].object.f.value
 'A1'
 ->> xx[10].object.f.value
 'A1'
 }}}
 Here, {{{xx[10].object}}} returns the correct object, however, when
 {{{xx[10].object.f}}} is evaluated it refers to model A instead of model
 B. This leads me to believe that there is some sort of faulty caching
 going on in the background that leads to model A being used.

 This bug was tested on 4.1.3, 3.2.16, 2.2.28 and was reproducible.

--

-- 
Ticket URL: 
Django 
The Web 

[Django] #34178: Prefetching a foreign key on GenericForeignKey results in incorrect queryset being selected

[Django]

#34178: Prefetching a foreign key on GenericForeignKey results in incorrect
queryset being selected
-+-
   Reporter:  Rohan  |  Owner:  nobody
  Nahata |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|   Keywords:  GenericForeignKey,
   Severity:  Normal |  prefetch_related
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 These are the models that I created to test my hypothesis. .
 {{{
 class Foreign(models.Model):
 value = models.CharField(max_length=20)

 class OtherForeign(models.Model):
 value = models.CharField(max_length=20)

 class A(models.Model):
 f = models.ForeignKey(Foreign, on_delete=models.PROTECT)

 class B(models.Model):
 f = models.ForeignKey(OtherForeign, on_delete=models.PROTECT)

 class X(models.Model):
 ct = models.ForeignKey(ContentType, on_delete=models.PROTECT)
 object_id = models.IntegerField()
 object = GenericForeignKey(ct_field='ct', fk_field='object_id')
 }}}

 The tables were populated with this sample data.
 {{{
 Foreign

 id|value
 1|A1
 2|A2
 3|A3
 4|A4
 5|A5
 6|A6
 7|A7
 8|A8
 9|A9
 10|A10


 Other Foreign

 id|value
 1|B1
 2|B2
 3|B3
 4|B4
 5|B5
 6|B6
 7|B7
 8|B8
 9|B9
 10|B10

 A

 id|f_id
 1|1
 2|2
 3|3
 4|4
 5|5
 6|6
 7|7
 8|8
 9|9
 10|10

 B

 id|f_id
 1|1
 2|2
 3|3
 4|4
 5|5
 6|6
 7|7
 8|8
 9|9
 10|10

 X
 id|object_id|ct_id
 1|1|11
 2|2|11
 3|3|11
 4|4|11
 5|5|11
 6|6|11
 7|7|11
 8|8|11
 9|9|11
 10|10|11
 11|1|10
 12|2|10
 13|3|10
 14|4|10
 15|5|10
 16|6|10
 17|7|10
 18|8|10
 19|9|10
 20|10|10

 }}}

 Based on this data :

 {{{
 ->> xx = X.objects.prefetch_related('object').all().order_by('id')
 ->> xx[0].object.f.value
 'A1'
 ->> xx[10].object.f.value
 'B1'
 }}}
 This behaviour is correct.

 However, when we chain another prefetch to the same,
 {{{
 ->> xx = X.objects.prefetch_related('object',
 'object__f').all().order_by('id')
 ->> xx[0].object.f.value
 'A1'
 ->> xx[10].object.f.value
 'A1'
 }}}
 Here, {{{xx[10].object}}} returns the correct object, however, when
 {{{xx[10].object.f}}} is evaluated it refers to model A instead of model
 B. This leads me to believe that there is some sort of faulty caching
 going on in the background that leads to model A being used.

-- 
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/010701849f27132a-6a2fd1f7-b8c6-4b6b-afce-30c1cdd5c0da-00%40eu-central-1.amazonses.com.

[Django] #34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.

[Django]

#34177: QuerySet.bulk_create() crashes on "pk" in unique_fields.
-+-
   Reporter:  Mariusz|  Owner:  Mariusz Felisiak
  Felisiak   |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `QuerySet.bulk_create()` crashes on `"pk"` in `unique_fields` which should
 be allowed.

 Bug in 0f6946495a8ec955b471ca1baaf408ceb53d4796.

-- 
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/010701849f2664c4-e3db6f89-b6a1-4926-9f18-2b4ba3e03643-00%40eu-central-1.amazonses.com.

[Django] #34176: Annotation's original field-name can clash with result field name over aggregation

[Django]

#34176: Annotation's original field-name can clash with result field name over
aggregation
-+-
   Reporter:  Shai   |  Owner:  nobody
  Berger |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Release|   Keywords:
  blocker|
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This is a bit of a continuation of #34123

 With current Django main, if one aggregates over a model, while adding
 annotations of related fields; and an annotation comes from a field with
 the same name as a result field, it breaks.

 This is easier to explain by example; consider this test, added to the
 {{{aggregation_regress}}} tests, so it uses their models; {{{Book}}}
 carries a FK to {{{Publisher}}}, a M2M to {{{Author}}} named
 {{{authors}}}, and a FK to {{{Author}}} (supposedly picking one of the
 related authors) named {{{contact}}}.

 {{{#!python
 def test_aggregate_and_annotate_duplicate_columns(self):
 results = Book.objects.values('isbn').annotate(
 name=F('publisher__name'),
 contact_name=F('contact__name'),
 num_authors=Count('authors'),
 )
 self.assertTrue(results)
 }}}

 The field {{{isbn}}} is not defined as unique, it was chosen in order to
 make sure there's an aggregation on the main table and not some sort of
 subquery -- and also, to get the {{{Book}}} model's own {{{name}}} field
 out of the way.

 This blows up on Sqlite:
 {{{
 ==
 ERROR: test_aggregate_and_annotate_duplicate_columns
 (aggregation_regress.tests.AggregationTests)
 --
 Traceback (most recent call last):
   File "/home/django/django/django/db/backends/utils.py", line 89, in
 _execute
 return self.cursor.execute(sql, params)
   File "/home/django/django/django/db/backends/sqlite3/base.py", line 378,
 in execute
 return super().execute(query, params)
 sqlite3.OperationalError: ambiguous column name: name
 }}}
 and on Postgres
 {{{
 ==
 ERROR: test_aggregate_and_annotate_duplicate_columns
 (aggregation_regress.tests.AggregationTests)
 --
 Traceback (most recent call last):
   File "/home/django/django/django/db/backends/utils.py", line 89, in
 _execute
 return self.cursor.execute(sql, params)
 psycopg2.errors.AmbiguousColumn: column reference "name" is ambiguous
 LINE 1: ..._id") GROUP BY "aggregation_regress_book"."isbn", "name", "c...
  ^
 }}}

 Note that if we change the {{{name}}} above to something else -- e.g.
 {{{#!python
 pub_name=F('publisher__name'),
 }}}
 then things seem to be working fine. Conversely, if we pick another
 related field for the name annotation:
 {{{#!python
 name=F('publisher__num_awards'),
 }}}
 then things stay broken.

 This used to work, and now it doesn't. I've bisected this regression to
 b7b28c7c189615543218e81319473888bc46d831.

 Thanks [https://www.matific.com Matific] for letting me work on this.

-- 
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/010701849f048910-c2a56c0c-d627-4c1c-824d-0163bd0bc441-00%40eu-central-1.amazonses.com.

Re: [Django] #34146: Add tutorial step for installing third party package(s)

[Django]

#34146: Add tutorial step for installing third party package(s)
-+-
 Reporter:  Timothy Schilling|Owner:  Timothy
 |  Schilling
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Marking as Patch needs improvement whilst in progress.

-- 
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/010701849f003e95-585640ce-ea29-4b00-8aec-57f14c8022e1-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code

[Django]

#34173: SessionMiddleware support 503 status code
--+--
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  4.1
 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
--+--

Comment (by SessionIssue):

 Replying to [comment:3 Mariusz Felisiak]:
 > I'm not sure why we should treat 503 differently. IMO, we could
 reconsider avoiding session saving when status code > 500 樂
 >
 > PS. Do not reopen tickets without further explanation.

 That would fix the problem and seems like a convenient solution to me.
 Thanks a lot! 

-- 
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/010701849ef41114-04a5057a-8c75-4fad-ac4d-db4254bcaf6b-00%40eu-central-1.amazonses.com.

Re: [Django] #33868: Admin “delete object(s)” view: improve labels of m2m relations

[Django]

#33868: Admin “delete object(s)” view: improve labels of m2m relations
-+-
 Reporter:   |Owner:  nobody
  jul...@pinabausch.org  |
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin, delete view   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Unreviewed


Comment:

 Closing as "wonfix" due to backward compatibility concerns and a possible
 performance regression. Users can always override `__str__` in their app,
 e.g.
 {{{#!python
 class FirstModel(models.Model):
 pass


 class SecondModel(models.Model):
 firsts = models.ManyToManyField(FirstModel)


 def to_str(self):
 return f"between {self.firstmodel} and {self.secondmodel}"


 SecondModel.firsts.through.__str__ = to_str
 }}}

-- 
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/010701849ebe95d1-e5f65108-4572-4511-906d-518f7fe6d652-00%40eu-central-1.amazonses.com.

Re: [Django] #33868: Admin “delete object(s)” view: improve labels of m2m relations

[Django]

#33868: Admin “delete object(s)” view: improve labels of m2m relations
-+-
 Reporter:   |Owner:  nobody
  jul...@pinabausch.org  |
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  admin, delete view   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jul...@pinabausch.org):

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


Comment:

 Closing this – the improved labels can only be implemented by fetching the
 “from” and “to” instances from the database, i.e. introducing a
 performance regression. The current implementation’s labels are created
 based on the models’ verbose names and the m2m instance’s ID, which is
 quite performance-friendly.

-- 
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/010701849ebc21f7-efc138a0-653b-4a6a-b9a3-b8ea96982f78-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code

[Django]

#34173: SessionMiddleware support 503 status code
--+--
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  4.1
 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 Mariusz Felisiak):

 * cc: Florian Apolloner, Anssi Kääriäinen (added)


Comment:

 I'm not sure why we should treat 503 differently. IMO, we could reconsider
 avoiding session saving when status code > 500 樂

 PS. Do not reopen tickets without further explanation.

-- 
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/010701849eb5d3dc-af6b17ee-b60f-4a9a-bc50-5698ae36a62c-00%40eu-central-1.amazonses.com.

Re: [Django] #34173: SessionMiddleware support 503 status code (was: SessionMiddleware only returns 400 or 500 error in case of DB issues.)

[Django]

#34173: SessionMiddleware support 503 status code
--+--
 Reporter:  SessionIssue  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  4.1
 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 SessionIssue):

 * status:  closed => new
 * type:  Bug => New feature
 * resolution:  invalid =>


Old description:

> Hi guys,
>
> I have the following situation. In one of my applications I'm having an
> issue with returning the right status code.
> For example I had this situation where I wanted to list 1000 results,
> this normally takes a couple of seconds, but during this request, my DB
> went offline or got stuck for some reason. Currently, this resulted in a
> 500 status code.
> As I have a custom controller that only retries tasks on specific status
> codes (like 503), I want to return a 503 status code (I also think that
> 503 is a more suitable one than 500 in this case), but this resulted in
> returning a 400 status code. The reason for that is the SessionMiddleware
> and particularly this part:
>
> {{{
> if response.status_code != 500:
> try:
> request.session.save()
> except UpdateError:
> raise SessionInterrupted(
> "The request's session was deleted before the
> "
> "request completed. The user may have logged
> "
> "out in a concurrent request, for example."
> )
> response.set_cookie(
> settings.SESSION_COOKIE_NAME,
> request.session.session_key, max_age=max_age,
> expires=expires,
> domain=settings.SESSION_COOKIE_DOMAIN,
> path=settings.SESSION_COOKIE_PATH,
> secure=settings.SESSION_COOKIE_SECURE or None,
> httponly=settings.SESSION_COOKIE_HTTPONLY or
> None,
> samesite=settings.SESSION_COOKIE_SAMESITE,
> )
> }}}
> As my DB is offline, this results in a 400 error, as the session can't be
> saved.
> I rewrote this small piece in a custom middleware that inherits the
> SessionMiddleware, but this is not a futureproof solution:
>
> {{{
> **if response.status_code not in [500, 503]:**
> try:
> request.session.save()
> except UpdateError:
> raise SessionInterrupted(
> "The request's session was deleted before the
> "
> "request completed. The user may have logged
> "
> "out in a concurrent request, for example."
> )
> response.set_cookie(
> settings.SESSION_COOKIE_NAME,
> request.session.session_key, max_age=max_age,
> expires=expires,
> domain=settings.SESSION_COOKIE_DOMAIN,
> path=settings.SESSION_COOKIE_PATH,
> secure=settings.SESSION_COOKIE_SECURE or None,
> httponly=settings.SESSION_COOKIE_HTTPONLY or
> None,
> samesite=settings.SESSION_COOKIE_SAMESITE,
> )
> }}}
>
> It's a small change, but it will make it hard for us to keep track of all
> the Django updates.
>
> Do you have a generic solution for this issue?
>
> Thanks in advance.

New description:

 Hi guys,

 I have the following situation. In one of my applications I'm having an
 issue with returning the right status code.
 For example I had this situation where I wanted to list 1000 results, this
 normally takes a couple of seconds, but during this request, my DB went
 offline or got stuck for some reason. Currently, this resulted in a 500
 status code.
 In the API client that interfaces with this code we want to return a 503
 because of an external source that only retries tasks on specific status
 codes (like 503), The current SessionMiddleware hijacks the statuscode and
 makes it impossible to raise a Service Unavailable (503).

 {{{
 if response.status_code != 500:
 try:
 request.session.save()
 except UpdateError:
 raise SessionInterrupted(
 "The request's session was deleted before the
 

Re: [Django] #34172: Documentation of AdminSite.get_urls() encourages security vulnerabilities

[Django]

#34172: Documentation of AdminSite.get_urls() encourages security 
vulnerabilities
-+-
 Reporter:  Sylvain Fankhauser   |Owner:  Sylvain
 Type:   |  Fankhauser
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.1
 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 Sylvain Fankhauser):

 * owner:  nobody => Sylvain Fankhauser
 * status:  new => assigned


Comment:

 Thanks for your feedback! I’ll work on a proposal soon.

-- 
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/010701849e8064ae-edbebf9f-b942-4ac5-a5fa-3b5b04b9ed1c-00%40eu-central-1.amazonses.com.

Re: [Django] #34172: Documentation of AdminSite.get_urls() encourages security vulnerabilities

[Django]

#34172: Documentation of AdminSite.get_urls() encourages security 
vulnerabilities
--+
 Reporter:  Sylvain Fankhauser|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  4.1
 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 Carlton Gibson):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I tend to agree with the report here:

 > ... as some people might stop reading there ...

 I think that's likely very common. Folks just copy and paste without
 really reading.

 I take Mariusz' point that it's explained, but if a re-phrase is on offer,
 having one correct example with a ''couple of things to note... '' below,
 I think we should have a look at that.

 I'll Accept on that basis (assuming that's why Mariusz left it unreviewed)

 > Interested in submitting a documentation PR?

 Sylvain, if you wanted to assign it to yourself and open a PR, that would
 be great.

-- 
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/010701849e75c978-009dc896-dfd5-4028-a043-1e61aab141ed-00%40eu-central-1.amazonses.com.