Re: [Django] #29229: QuerySet.values_list() combined with .extra() or .annotate() may produce wrong .union()

[Django]

#29229: QuerySet.values_list() combined with .extra() or .annotate() may produce
wrong .union()
-+-
 Reporter:  master   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  union values_list| 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 Tim Graham ):

 In [changeset:"c5bb472095f02df364f9a0ce64f0b97bfd4a8c63" c5bb472]:
 {{{
 #!CommitTicketReference repository=""
 revision="c5bb472095f02df364f9a0ce64f0b97bfd4a8c63"
 [1.11.x] Fixed #29229 -- Fixed column mismatch crash when combining two
 annotated values_list() querysets with union(), difference(), or
 intersection().

 Regression in 7316720603821ebb64dfe8fa592ba6edcef5f3e.

 Backport of a0c03c62a8ac586e5be5b21393c925afa581efaf from master
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7c8ba35cda1c655f80962a8514a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29229: QuerySet.values_list() combined with .extra() or .annotate() may produce wrong .union()

[Django]

#29229: QuerySet.values_list() combined with .extra() or .annotate() may produce
wrong .union()
-+-
 Reporter:  master   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  union values_list| 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 Tim Graham ):

 In [changeset:"9123fd75caa595c018d4121575cbada80226b4f2" 9123fd7]:
 {{{
 #!CommitTicketReference repository=""
 revision="9123fd75caa595c018d4121575cbada80226b4f2"
 [2.0.x] Fixed #29229 -- Fixed column mismatch crash when combining two
 annotated values_list() querysets with union(), difference(), or
 intersection().

 Regression in 7316720603821ebb64dfe8fa592ba6edcef5f3e.

 Backport of a0c03c62a8ac586e5be5b21393c925afa581efaf from master
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6fbfc49f98c13f3331490d8e8bc9a4b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29229: QuerySet.values_list() combined with .extra() or .annotate() may produce wrong .union()

[Django]

#29229: QuerySet.values_list() combined with .extra() or .annotate() may produce
wrong .union()
-+-
 Reporter:  master   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  union values_list| 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 Tim Graham ):

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


Comment:

 In [changeset:"a0c03c62a8ac586e5be5b21393c925afa581efaf" a0c03c62]:
 {{{
 #!CommitTicketReference repository=""
 revision="a0c03c62a8ac586e5be5b21393c925afa581efaf"
 Fixed #29229 -- Fixed column mismatch crash when combining two annotated
 values_list() querysets with union(), difference(), or intersection().

 Regression in 7316720603821ebb64dfe8fa592ba6edcef5f3e.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.41302de0ca9e5376268bc03d49cd97e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10827: django.auth create_permissions must clear the content type cache before creating permissions

[Django]

#10827: django.auth create_permissions must clear the content type cache before
creating permissions
+
 Reporter:  Sean Legassick  |Owner:  (none)
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Jared Proffitt):

 Michał's fix work for me as well. If I move
 `'django.contrib.contenttypes'` before `'django.contrib.auth'` in
 `INSTALLED_APPS`, it works.

 Would be nice to either have a fix that doesn't require that specific
 order of apps, or some documentation mentioning you need the specific app
 order.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.f581d1e20d77dc635323023522960e21%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27654: Propogate alters_data value to subclasses

[Django]

#27654: Propogate alters_data value to subclasses
--+
 Reporter:  vinay karanam |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 After looking at the implementation on the PR, the proposed metaclass
 solution is too much to given the relatively small improvement over the
 current `alters_data` solution.

 The remaining suggestion from #27638 was to use the system checks
 framework to warn users of a problem. That might be worth a go. It would
 be able to capture the most common cases on `Model` classes certainly.
 (Whether we want to add that isn't clear: in lots of cases `save` is
 overridden without setting `alters_data` — to make that an error might be
 more annoying than a benefit, but it could at least be silenced.)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.5a3ddd055ca93949204135d8433ebed9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29240: https://code.djangoproject.com/ticket/ - sending emails

[Django]

#29240: https://code.djangoproject.com/ticket/ - sending emails
+--
 Reporter:  Дилян Палаузов  |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Uncategorized   |  Version:  2.0
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Simon Charette):

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


Comment:

 Whether or not the `"(was: {old summary})"` cluters or not the email is up
 for debate but in all cases this should be reported to the Trac project.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.1681196f3382453d1b2f79e465d566fc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29239: GEOSGeometry treats WKB and WKT input differently (former incorrectly) (was: GEOSGeometry treats WKB and WKT input differently (former fails))

[Django]

#29239: GEOSGeometry treats WKB and WKT input differently (former incorrectly)
+
 Reporter:  MatBurnham  |Owner:  Jani Tiainen
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Old description:

> I've been trying to load an OpenStreetMap-derived multipolygon geometry
> from PostGIS but it fails due to trying to incorrectly load a non-closed
> shape into GeoDjango as a LinearRing. In trying to create a GEOSGeometry
> object manually from the same data, I identified a difference depending
> on the format presented - hex-encoded WKB fails in the way described; the
> same shape pre-converted in PostGIS to WKT works fine.
>
> {{{
> >>> from django.contrib.gis.geos import GEOSGeometry
> >>> wkt = 'MULTIPOLYGON(((-0.45747735963738 51.4742768635629 0
> -1.79769313486232e+308,-0.457470821752906 51.474364454451 0
> -1.79769313486232e+308,-0.452403039275168 51.4743796256958 0
> -1.79769313486232e+308,-0.452246046228737 51.4742687331168 0
> -1.79769313486232e+308,-0.452112857787284 51.4742487841872 0
> -1.79769313486232e+308,-0.451990649639015 51.4742207886306 0
> -1.79769313486232e+308,-0.451845642714119 51.4741605227468 0
> -1.79769313486232e+308,-0.451582534773507 51.4742741813538 0
> -1.79769313486232e+308,-0.451456303311716 51.4741789629338 0
> -1.79769313486232e+308,-0.450938804609791 51.4744128180323 0
> -1.79769313486232e+308,-0.450789858190376 51.4743100558994 0
> -1.79769313486232e+308,-0.450504957301519 51.4744324316858 0
> -1.79769313486232e+308,-0.450413426918857 51.474364454451 0
> -1.79769313486232e+308,-0.450372439412348 51.4743808829813 0
> -1.79769313486232e+308,-0.450428346706502 51.4744274863629 0
> -1.79769313486232e+308,-0.450302031425679 51.4744810467242 0
> -1.79769313486232e+308,-0.450105475796278 51.4743131572036 0
> -1.79769313486232e+308,-0.449894754750488 51.4744009995489 0
> -1.79769313486232e+308,-0.44991193765199 51.4744175957171 0
> -1.79769313486232e+308,-0.449809762252301 51.4744640314607 0
> -1.79769313486232e+308,-0.449963905451682 51.4746087869285 0
> -1.79769313486232e+308,-0.449909674538134 51.4746315857052 0
> -1.79769313486232e+308,-0.450032469419625 51.4746683822601 0
> -1.79769313486232e+308,-0.449577751172455 51.4748623394995 0
> -1.79769313486232e+308,-0.448971236658821 51.4748638482421 0
> -1.79769313486232e+308,-0.448931925532946 51.4748438993126 0
> -1.79769313486232e+308,-0.448518949163599 51.4748311588197 0
> -1.79769313486232e+308,-0.448473100153223 51.4748489284545 0
> -1.79769313486232e+308,-0.447686709997498 51.4748498504638 0
> -1.79769313486232e+308,-0.447684782159769 51.4748206814408 0
> -1.79769313486232e+308,-0.448265983325825 51.4748150655657 0
> -1.79769313486232e+308,-0.448188869816619 51.4747476750641 0
> -1.79769313486232e+308,-0.44829791241 51.4747361918568 0
> -1.79769313486232e+308,-0.448208148193913 51.4747211882501 0
> -1.79769313486232e+308,-0.448329434332834 51.4746639398514 0
> -1.79769313486232e+308,-0.448478213114157 51.4747982179402 0
> -1.79769313486232e+308,-0.448560355765267 51.4748005648731 0
> -1.79769313486232e+308,-0.448630512294841 51.4747671210795 0
> -1.79769313486232e+308,-0.44869547204442 51.4747617566615 0
> -1.79769313486232e+308,-0.448988754836478 51.4746377883135 0
> -1.79769313486232e+308,-0.448919436497221 51.4745831383048 0
> -1.79769313486232e+308,-0.448959082899222 51.4745629379182 0
> -1.79769313486232e+308,-0.448913736803064 51.4745073659001 0
> -1.79769313486232e+308,-0.448979702381024 51.4744776939629 0
> -1.79769313486232e+308,-0.44899328106419 51.4744893448083 0
> -1.79769313486232e+308,-0.449082129237809 51.474446178007 0
> -1.79769313486232e+308,-0.449221352649516 51.4745348585425 0
> -1.79769313486232e+308,-0.449859718395231 51.4742688169358 0
> -1.79769313486232e+308,-0.449742120293706 51.4741538172243 0
> -1.79769313486232e+308,-0.450747781036455 51.4737123423841 0
> -1.79769313486232e+308,-0.450597912607719 51.4735824228849 0
> -1.79769313486232e+308,-0.450489450780651 51.4736291939047 0
> -1.79769313486232e+308,-0.450386101914518 51.4735359871414 0
> -1.79769313486232e+308,-0.450340169085138 51.4734947481778 0
> -1.79769313486232e+308,-0.450237071676099 51.4734032177951 0
> -1.79769313486232e+308,-0.450144451646025 51.4734446243968 0
> -1.79769313486232e+308,-0.449599963215888 51.4729609885837 0
> -1.79769313486232e+308,-0.44955746696678 51.4729753216381 0
> -1.79769313486232e+308,-0.449539948789152 51.4730110285456 0
> -1.79769313486232e+308,-0.449296622140025 

[Django] #29240: https://code.djangoproject.com/ticket/ - sending emails

[Django]

#29240: https://code.djangoproject.com/ticket/ - sending emails
--+
   Reporter:  Дилян Палаузов  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  2.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When a file is uploaded at https://code.djangoproject.com/ticket/{id} with
 the option "Replace existing attachment of the same name" an email is
 sent.  The email has a subject containing the ticket number and a summary
 of the ticket description.

 If the ticket description was ever changed, then the subject is "Re:
 [Django] #ID: {current summary (was: {old summary})".

 On such occasions the "(was: {old summary})" part shall not be sent as it
 only clutters the email.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.9122ba156c6c4d54fd9f4c5ac654efbe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28643: Complete the ORM Function Library

[Django]

#28643: Complete the ORM Function Library
-+-
 Reporter:  Matthew Pava |Owner:  JunyiJ
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 GitHub ):

 In [changeset:"cede5111bbeea1f02a7d35941a4264c7ff95df0a" cede5111]:
 {{{
 #!CommitTicketReference repository=""
 revision="cede5111bbeea1f02a7d35941a4264c7ff95df0a"
 Refs #28643 -- Added LPad and RPad database functions.

 Thanks Tim Graham for the review.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.521763d851cf03431aa487a9823b1220%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

[Django]

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Tom Forbes):

 Hey, please create a branch on Github and submit a Pull Request with these
 changes if you want them to be reviewed and tested.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.059a30f6bbf2697cc7624bbb06eff00b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

[Django]

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Дилян Палаузов):

 * Attachment "on_conflict_ignore.2.patch" added.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.882d34a364880c8b27c4350a8b01de5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29229: QuerySet.values_list() combined with .extra() or .annotate() may produce wrong .union()

[Django]

#29229: QuerySet.values_list() combined with .extra() or .annotate() may produce
wrong .union()
-+-
 Reporter:  master   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  union values_list| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Regression introduced in 2.0, still present in 2.0.3.
>
> Easy context to reproduce the problem: suppose a Message model, in a
> postman app. Only one ordinary field is enough for the demo.
>
> {{{#!python
> qs1 = Message.objects.extra(select={'count': 0}).values_list('id',
> 'count').order_by()
> print(qs1.query)  # as expected:
> # SELECT (0) AS "count", "postman_message"."id"
> # FROM "postman_message"
>
> qs2 =
> Message.objects.values('somefield').annotate(count=models.Count('pk')).annotate(id=models.Max('pk')).values_list('id',
> 'count').order_by()
> print(qs2.query)  # as expected:
> # SELECT COUNT("postman_message"."id") AS "count",
> MAX("postman_message"."id") AS "id"
> # FROM "postman_message" GROUP BY "postman_message"."somefield"
>
> print(qs1.union(qs2).query)  # !! WRONG !! the qs2 part is truncated:
> # SELECT (0) AS "count", "postman_message"."id" FROM "postman_message"
> # UNION
> # SELECT MAX("postman_message"."id") AS "id" FROM "postman_message" GROUP
> BY "postman_message"."somefield"
> }}}
>
> Compared to version 1.11, it comes from this addition in
> db/models/sql/compiler.py/get_combinator_sql():
> {{{#!python
> if not compiler.query.values_select and self.query.values_select:
> compiler.query.set_values(self.query.values_select)
> }}}
> Here, self.query.values_select is ('id',).
> For qs2, values_select is indeed empty, as coded in
> db/models/sql/query.py/set_values(),
> because in this case the two values_list() arguments are managed in
> annotation_names[].

New description:

 Regression introduced in 2.0, still present in 2.0.3 [Edit: and backported
 in 1.11.8].

 Easy context to reproduce the problem: suppose a Message model, in a
 postman app. Only one ordinary field is enough for the demo.

 {{{#!python
 qs1 = Message.objects.extra(select={'count': 0}).values_list('id',
 'count').order_by()
 print(qs1.query)  # as expected:
 # SELECT (0) AS "count", "postman_message"."id"
 # FROM "postman_message"

 qs2 =
 
Message.objects.values('somefield').annotate(count=models.Count('pk')).annotate(id=models.Max('pk')).values_list('id',
 'count').order_by()
 print(qs2.query)  # as expected:
 # SELECT COUNT("postman_message"."id") AS "count",
 MAX("postman_message"."id") AS "id"
 # FROM "postman_message" GROUP BY "postman_message"."somefield"

 print(qs1.union(qs2).query)  # !! WRONG !! the qs2 part is truncated:
 # SELECT (0) AS "count", "postman_message"."id" FROM "postman_message"
 # UNION
 # SELECT MAX("postman_message"."id") AS "id" FROM "postman_message" GROUP
 BY "postman_message"."somefield"
 }}}

 Compared to version 1.11 [Edit: I run 1.11.7 precisely], it comes from
 this addition in db/models/sql/compiler.py/get_combinator_sql():
 {{{#!python
 if not compiler.query.values_select and self.query.values_select:
 compiler.query.set_values(self.query.values_select)
 }}}
 Here, self.query.values_select is ('id',).
 For qs2, values_select is indeed empty, as coded in
 db/models/sql/query.py/set_values(),
 because in this case the two values_list() arguments are managed in
 annotation_names[].

--

Comment (by master):

 Precisions about versions.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b779afb5add0ac0de72b34af8c0afa99%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27991: Add 'obj' kwarg to InlineModelAdmin.has_add_permission()

[Django]

#27991: Add 'obj' kwarg to InlineModelAdmin.has_add_permission()
-+-
 Reporter:  Olivier  |Owner:  Vladimir
 Type:   |  Ivanov
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.31143c4666378bb9145f774cefaab480%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28574: Add a QuerySet.explain() method

[Django]

#28574: Add a QuerySet.explain() method
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   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:  Accepted => Ready for checkin


Comment:

 This looks ready to go. Good work Tom!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.83146501107bc2b4af8cd122f468047d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29239: GEOSGeometry treats WKB and WKT input differently (former fails)

[Django]

#29239: GEOSGeometry treats WKB and WKT input differently (former fails)
+
 Reporter:  MatBurnham  |Owner:  Jani Tiainen
 Type:  Bug |   Status:  assigned
Component:  GIS |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Jani Tiainen):

 * owner:  nobody => Jani Tiainen
 * status:  new => assigned


Comment:

 Django passes geometries to GEOS library so error originates from there.

 Now few notes about WKT geometry is it XYZM geometry since it seems to
 contain 4 values per point?

 Django supports only 3D geometries so you may lose data here. Also tried
 to decode WKB but from the quick look it looked like WKB from postgis
 (because AFAIK it uses geos as well as underlying library).

 Few points from geometry.
 {{{
 -0.45747735963738   51.4742768635629 0 -1.79769313486232e+308,
 -0.457470821752906 51.474364454451   0 -1.79769313486232e+308,
 }}}

 Version of installed GEOS libraries would be useful information 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.25ac1af04af5ad6ec95084e8c454ae3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29229: QuerySet.values_list() combined with .extra() or .annotate() may produce wrong .union()

[Django]

#29229: QuerySet.values_list() combined with .extra() or .annotate() may produce
wrong .union()
-+-
 Reporter:  master   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  union values_list| 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 Tim Graham):

 * needs_better_patch:  1 => 0
 * version:  2.0 => 1.11
 * stage:  Accepted => Ready for checkin


Comment:

 This affects Django 1.11.8 and later, due to
 67316720603821ebb64dfe8fa592ba6edcef5f3e.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.24ab6fffc860c05cebe944c4cf65441b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances during multilevel data prefetching

[Django]

#29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances
during multilevel data prefetching
-+-
 Reporter:  Alex Sichkar |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 I found that your test case was fixed in Django 2.0 by
 379caf397ea41923278821085204c296f960e70e. Since a regression test wasn't
 added as part of that commit, I'll accept the ticket to do that. If you
 can adapt your test for `tests/prefetch_related` (using existing models as
 much as possible) 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ac87155ef3777f3a97ce495af97685f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29223: Dummy database backend's is_usable() method should return False

[Django]

#29223: Dummy database backend's is_usable() method should return False
-+-
 Reporter:  Wagner Macedo|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.6769cb63ffd2cd0d1e7ff9b0979533aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28462: ModelAdmin.list_editable unusably slow and memory intensive with large datasets

[Django]

#28462: ModelAdmin.list_editable unusably slow and memory intensive with large
datasets
---+
 Reporter:  Ben Cole   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * easy:  1 => 0


Comment:

 I don't think reverting is a good idea as that reintroduces possible data
 loss.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.94f44c2192f75e32e581f6982772dc81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29239: GEOSGeometry treats WKB and WKT input differently (former fails)

[Django]

#29239: GEOSGeometry treats WKB and WKT input differently (former fails)
+--
 Reporter:  MatBurnham  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  GIS |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by MatBurnham):

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


Comment:

 The geometry IS valid. Formatted as WKT it is accepted. The same geometry
 formatted as hex encoded WKB is misinterpreted as LinearRing when it
 should be a MultiPolygon.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c0e790fb2aa751094495aa2ba3a9f029%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29238: psycopg2.InterfaceError in sequential tests after HTTP 404

[Django]

#29238: psycopg2.InterfaceError in sequential tests after HTTP 404
---+--
 Reporter:  alubbock   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 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 Tim Graham):

 I can't reproduce the problem with the test file you provided. Perhaps I'm
 missing some other detail. Can you please provide a sample project that
 reproduces the issue (without any third-party dependencies to rule out a
 problem there)?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e7a94ea303a11d84b24930f12bd55e67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28462: ModelAdmin.list_editable unusably slow and memory intensive with large datasets

[Django]

#28462: ModelAdmin.list_editable unusably slow and memory intensive with large
datasets
---+
 Reporter:  Ben Cole   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Pablo Martín):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fd7af933fac67aaf8e69b54a3596af20%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use to_field

[Django]

#29138: Add ModelAdmin.autocomplete_fields support for ForeignKeys that use
to_field
---+--
 Reporter:  Jonathan Nye   |Owner:  Basu Dubey
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.0
 Severity:  Normal |   Resolution:
 Keywords:  autocomplete   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Johannes Hoppe):

 Cool, let me know when you have patch. I am happy to review it :)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.cfd68ad28f7e751738e4f55e5b6ddd30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29173: Document that Model.save() doesn't refresh fields from the database

[Django]

#29173: Document that Model.save() doesn't refresh fields from the database
--+
 Reporter:  Xtreak|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:  invalid
 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):

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


Comment:

 The ''Custom Model Fields'' How-To discusses this usage explicitly in the
 [https://docs.djangoproject.com/en/2.0/howto/custom-model-fields
 /#preprocessing-values-before-saving Preprocessing values before saving]
 section.

 It suggests using `pre_save(model_instance, add)` for this kind of
 behaviour.

 It explicitly makes updating the model's attribute the user's
 responsibility:

 > You should also update the model’s attribute if you make any changes to
 the value so that code holding references to the model will always see the
 correct value.

 Note `pre_save` takes the `model_instance` parameter precisely for this
 purpose.

 The canonical example of this usage is from `DateTimeField`, for handling
 `auto_now` and `auto_now_add`:

 {{{
 def pre_save(self, model_instance, add):
 if self.auto_now or (self.auto_now_add and add):
 value = datetime.date.today()
 setattr(model_instance, self.attname, value)
 return value
 else:
 return super().pre_save(model_instance, add)
 }}}

 The quoted line from the docs was
 
[https://github.com/django/django/commit/8216abe74889cc867a4cf89e6708f37cec6b2e72
 introduced in 2007] so this behaviour (and expected usage) is part of the
 original design of the `Field` API. As such I'm going to close this
 ticket.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.de29a1a845c7adba728993bb44034186%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29239: GEOSGeometry treats WKB and WKT input differently (former fails)

[Django]

#29239: GEOSGeometry treats WKB and WKT input differently (former fails)
+--
 Reporter:  MatBurnham  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  2.0
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Jani Tiainen):

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


Comment:

 Problem seems to originate from GEOS library itself (native library) which
 apparently treats different types of data slightly differently.

 In any case, you geometry is not valid thus Django is not at fault. If
 problem persists with a valid geometry please reopen the ticket.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.4a1c619aba1b351aff3617df8d9b919e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.