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

2023-01-09 Thread Django
#34176: Annotation's original field-name can clash with result field name over
aggregation
-+-
 Reporter:  Shai Berger  |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (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:"dd68af62b2b27ece50d434f6a351877212e15c3f" dd68af62]:
 {{{
 #!CommitTicketReference repository=""
 revision="dd68af62b2b27ece50d434f6a351877212e15c3f"
 Fixed #34176 -- Fixed grouping by ambiguous aliases.

 Regression in b7b28c7c189615543218e81319473888bc46d831.

 Refs #31377.

 Thanks Shai Berger for the report and reviews.

 test_aggregation_subquery_annotation_values_collision() has been
 updated as queries that are explicitly grouped by a subquery should
 always be grouped by it and not its outer columns even if its alias
 collides with referenced table columns. This was not possible to
 accomplish at the time 10866a10 landed because we didn't have compiler
 level handling of 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/01070185964a37ae-4b9835e7-9f80-43e3-846d-0935a4a80b12-00%40eu-central-1.amazonses.com.


Re: [Django] #31377: Django 3.0: "GROUP BY" clauses error with tricky field annotation

2023-01-09 Thread Django
#31377: Django 3.0: "GROUP BY" clauses error with tricky field annotation
-+-
 Reporter:  Holovashchenko   |Owner:  Hasan
  Vadym  |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  group by, postgres,  | Triage Stage:  Ready for
  annotate   |  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:"dd68af62b2b27ece50d434f6a351877212e15c3f" dd68af62]:
 {{{
 #!CommitTicketReference repository=""
 revision="dd68af62b2b27ece50d434f6a351877212e15c3f"
 Fixed #34176 -- Fixed grouping by ambiguous aliases.

 Regression in b7b28c7c189615543218e81319473888bc46d831.

 Refs #31377.

 Thanks Shai Berger for the report and reviews.

 test_aggregation_subquery_annotation_values_collision() has been
 updated as queries that are explicitly grouped by a subquery should
 always be grouped by it and not its outer columns even if its alias
 collides with referenced table columns. This was not possible to
 accomplish at the time 10866a10 landed because we didn't have compiler
 level handling of 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/01070185964a37c3-89fe2557-7046-4968-9f69-f4cff2c5b6d7-00%40eu-central-1.amazonses.com.


Re: [Django] #30240: Add support for SHA database functions.

2023-01-09 Thread Django
#30240: Add support for SHA database functions.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sha1, sha224,| Triage Stage:  Ready for
  sha256, sha384, sha512 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"04fdf719331dde6b0f4e7cdc445be4d4278f3ec4" 04fdf71]:
 {{{
 #!CommitTicketReference repository=""
 revision="04fdf719331dde6b0f4e7cdc445be4d4278f3ec4"
 Refs #30240 -- Fixed argument name for MySQLSHA2Mixin.as_mysql() and
 PostgreSQLSHAMixin.as_postgresql() methods.
 }}}

-- 
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/01070185967caaab-5a859e4e-c5ce-44aa-ae58-4cb393348132-00%40eu-central-1.amazonses.com.


[Django] #34247: Cannot resolve operation dependencies

2023-01-09 Thread Django
#34247: Cannot resolve operation dependencies
+
   Reporter:  michaelschem  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Migrations|Version:  4.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 I've been having trouble regenerating all my Django migrations from
 scratch. We have hundreds of models and many complex relationships. I kept
 getting the error `Cannot resolve operation dependencies` when generating
 and I noticed that proxy models that were foreign keys of other models
 seemed to be the culprit. I've created a pr to fix the sort method to
 ensure that proxy model based CreateModel and regular model CreateModel
 operations are at the top.

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

-- 
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/0107018597fa04a1-bc555d7c-cc53-4c23-b89a-1b2e7dc780f6-00%40eu-central-1.amazonses.com.


Re: [Django] #34247: Cannot resolve operation dependencies

2023-01-09 Thread Django
#34247: Cannot resolve operation dependencies
+--
 Reporter:  Mike Schem  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  4.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * needs_tests:  0 => 1
 * easy:  1 => 0


Comment:

 You'll need to provide a minimal example to reproduce the issue so we can
 better understand it. The patch also requires a regression test based on
 that.

-- 
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/0107018597fee41a-3691b23c-19e8-45bd-88fe-4189cb6fbfbf-00%40eu-central-1.amazonses.com.


[Django] #34248: sdist is missing tox.ini

2023-01-09 Thread Django
#34248: sdist is missing tox.ini
-+
   Reporter:  Marcel Telka   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Testing framework  |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 The sdist package at PyPI is missing tox.ini file.  Please add the file
 into the sdist to make downstream testing easier.  Thank you.

-- 
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/01070185983eb330-bc1658dc-7f93-4b62-9fb5-89931a27e448-00%40eu-central-1.amazonses.com.


Re: [Django] #34248: sdist is missing tox.ini

2023-01-09 Thread Django
#34248: sdist is missing tox.ini
--+
 Reporter:  Marcel Telka  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Packaging |  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 Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Testing framework => Packaging
 * stage:  Unreviewed => Accepted


Comment:

 An addition is needed to MANIFEST.in.

-- 
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/01070185988cd0d0-eb01ff8d-e4d5-4da7-b9fa-561b456b01ff-00%40eu-central-1.amazonses.com.


Re: [Django] #34247: Cannot resolve operation dependencies

2023-01-09 Thread Django
#34247: Cannot resolve operation dependencies
+--
 Reporter:  Mike Schem  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  4.1
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | 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):

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


-- 
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/010701859a77f012-945e34e3-e7e1-4167-9df7-0e44182777fc-00%40eu-central-1.amazonses.com.


Re: [Django] #34242: Behavior of Model.delete() with regards to primary_key fields is not documented

2023-01-09 Thread Django
#34242: Behavior of Model.delete() with regards to primary_key fields is not
documented
--+
 Reporter:  SwampFalc |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 I think something as small as... "the Python instance will still exist and
 will still have data in its fields, but the primary key is set to `None`"
 in the [https://docs.djangoproject.com/en/4.1/ref/models/instances
 /#deleting-objects Deleting objects] docs you point to, would likely be
 enough.

 > You know, thinking about it some more... What exactly is the reason for
 setting the PK to None upon deletion? Is that really necessary?

 Standardly, whether the object has a PK is the test whether it's been
 saved (i.e. exists in the DB). I doubt that's changeable.
 (Others may give a better account.)

-- 
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/010701859a902ce6-e52300ee-a87e-4c8b-a2db-ef8674c9302d-00%40eu-central-1.amazonses.com.


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

2023-01-09 Thread Django
#31014: add FromWKB and FromWKT GIS functions
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  wkt, wkb | 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:  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/010701859a970e67-efbfc22c-3539-481a-a2ed-9b836452b872-00%40eu-central-1.amazonses.com.


Re: [Django] #33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.

2023-01-09 Thread Django
#33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.
-+-
 Reporter:  Alan |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql truncdate  | Triage Stage:  Accepted
  timezone   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kenneth Lim):

 Strictly speaking, would this be better handled by modifying the name
 handling instead? Here we'll convert directly from etc/GMT+9 -> "-9:00",
 rather than passing "etc/GMT+9" directly over to mysql

-- 
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/010701859ab04228-3a30e208-4c88-4902-aef6-c061d3391c75-00%40eu-central-1.amazonses.com.