Re: [Django] #31552: Loading lzma compressed fixtures

[Django]

#31552: Loading lzma compressed fixtures
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 Type:   |  Melchiorre
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  fixtures | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
-+-
 Reporter:  Kyle |Owner:  Kyle
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  date_hierarchy   | 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:"ef19aec2caab1ad246fd48ba1cf7c02e05706a5d" ef19aec2]:
 {{{
 #!CommitTicketReference repository=""
 revision="ef19aec2caab1ad246fd48ba1cf7c02e05706a5d"
 [3.1.x] Fixed #31590 -- Fixed ModelAdmin.date_hierarchy crash with an
 empty QuerySet.

 Regression in 55cdf6c52db07f29128741b8734a523ed042e465.

 Backport of 099bce1bf0b9802b7159beb9260b9b9e344bf497 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.adf997e4df2315011622aa7d7bf7d8e1%40djangoproject.com.

Re: [Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
-+-
 Reporter:  Kyle |Owner:  Kyle
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  date_hierarchy   | 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:"099bce1bf0b9802b7159beb9260b9b9e344bf497" 099bce1b]:
 {{{
 #!CommitTicketReference repository=""
 revision="099bce1bf0b9802b7159beb9260b9b9e344bf497"
 Fixed #31590 -- Fixed ModelAdmin.date_hierarchy crash with an empty
 QuerySet.

 Regression in 55cdf6c52db07f29128741b8734a523ed042e465.
 }}}

-- 
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/067.d83689c79fb3607ff89946b444f95801%40djangoproject.com.

Re: [Django] #31587: List filters are selected only for queries with explicit __exact lookups. (was: Django admin - list_filter visually selected for query using implicit xx__id__exact)

[Django]

#31587: List filters are selected only for queries with explicit __exact 
lookups.
---+--
 Reporter:  Anael Mobilia  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 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 felixxm):

 * status:  new => closed
 * type:  Uncategorized => New feature
 * version:  3.0 => master
 * resolution:   => wontfix


Comment:

 Thanks for this ticket, however that's how the admin is implemented. We
 use explicit lookups also in other filters. I don't see much value in
 supporting other lookup shortcuts in each filter. You can always subclass
 `RelatedFieldListFilter` if you really need 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/070.e9c01a71cc22f4e40b95b4baf4dcc01f%40djangoproject.com.

Re: [Django] #31577: The explanation ended in the middle.

[Django]

#31577: The explanation ended in the middle.
-+-
 Reporter:  Joon Hwan 김준환 |Owner:  Joon Hwan
 Type:   |  김준환
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.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 Joon Hwan 김준환):

 * owner:  nobody => Joon Hwan 김준환
 * 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/063.a385fcbe3884cbfed1d841b05952c06c%40djangoproject.com.

Re: [Django] #31577: The explanation ended in the middle.

[Django]

#31577: The explanation ended in the middle.
-+-
 Reporter:  Joon Hwan 김준환 |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.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 Joon Hwan 김준환):

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


Comment:

 Let me provide PR as soon as possible.

-- 
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/063.c0a91ad0888d4db2dc9adcf14b20f7df%40djangoproject.com.

Re: [Django] #31586: Small mistake in 'Writing your first Django app, part 4' tutorial

[Django]

#31586: Small mistake in 'Writing your first Django app, part 4' tutorial
---+--
 Reporter:  Mikolaj Kaczmarek  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  master
 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 Tim Graham):

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


Comment:

 It's correct as is. The link goes to the page where the user can vote, not
 to the view that processes the results of voting.

-- 
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/064.683e61506888ee60e5b5f44c915210a8%40djangoproject.com.

Re: [Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
-+-
 Reporter:  Kyle |Owner:  Kyle
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  date_hierarchy   | 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 Simon Charette):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Ready for checkin


Comment:

 Patch LGTM pending two cosmetic adjustments.

-- 
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/067.a47a08b47a9cdd530199e578510bc35b%40djangoproject.com.

Re: [Django] #31583: Extend deferred unique constraint support to OneToOneField

[Django]

#31583: Extend deferred unique constraint support to OneToOneField
-+-
 Reporter:  BorisZZZ |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  DEFERRED | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Not sure we should do that as it seems pretty niche.

 I guess an alternative API could be to allow passing a `UniqueConstraint`
 to the `unique` kwarg like we've discussed doing to the `Field.index` one.

 e.g.

 {{{#!python
 OneToOneField(OtherModel,
 unique=UniqueConstraint(defer=models.Deferrable.DEFERRED))
 }}}

-- 
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/066.0ff73c630eb6bcb1215405109303515c%40djangoproject.com.

Re: [Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
+--
 Reporter:  Kyle|Owner:  Kyle
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  3.1
 Severity:  Normal  |   Resolution:
 Keywords:  date_hierarchy  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Kyle):

 * has_patch:  0 => 1


Comment:

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

-- 
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/067.13e6265004caf5bc3a9a0b50e82a8ba5%40djangoproject.com.

Re: [Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
+--
 Reporter:  kjpc-tech   |Owner:  kjpc-tech
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  3.1
 Severity:  Normal  |   Resolution:
 Keywords:  date_hierarchy  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by kjpc-tech):

 * owner:  nobody => kjpc-tech
 * 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/067.ad22897c4751ae4b27ed72b5d401d84c%40djangoproject.com.

[Django] #31590: Admin date_hierarchy crashes on datetime field with no data

[Django]

#31590: Admin date_hierarchy crashes on datetime field with no data
-+
   Reporter:  kjpc-tech  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.1
   Severity:  Normal |   Keywords:  date_hierarchy
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Just upgraded to Django 3.1 alpha and ran into this issue. It looks like
 its related to commit 55cdf6c52db07f29128741b8734a523ed042e465. When there
 is no data in the admin or all values are null, a date hierarchy on a
 datetime field will cause a crash.


 {{{
 File "django/contrib/admin/templatetags/admin_list.py", line 386, in
 date_hierarchy
   for k, v in date_range.items()
 File "django/contrib/admin/templatetags/admin_list.py", line 386, in
 
   for k, v in date_range.items()
 File "django/utils/timezone.py", line 212, in is_aware
   return value.utcoffset() is not None

 Exception Value: 'NoneType' object has no attribute 'utcoffset'
 }}}


 I'm starting work on a fix.

-- 
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/052.a246d898ae8839ae86664c605d882718%40djangoproject.com.

Re: [Django] #31506: ExpressionWrapper() doesn't respect output_field when combining DateField and timedelta on PostgreSQL and MySQL.

[Django]

#31506: ExpressionWrapper() doesn't respect output_field when combining 
DateField
and timedelta on PostgreSQL and MySQL.
-+-
 Reporter:  Matthieu Rigal   |Owner:
 |  TapanGujjar
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 TapanGujjar):

 Hi, the issue is because the DateField has no field converter or
 db_converter to convert the value which we got from the database to the
 DateField type. I can implement the field converter for the data field but
 Is the DateField not having the field converter or db_converter by design?

-- 
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/064.95eb3254df19fa810536d388ca88c9e7%40djangoproject.com.

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

[Django]

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

 * cc: Markus Zapke-Gründemann (added)


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

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

Re: [Django] #31546: Replace Command.requires_system_checks = True by something like Command.required_system_checks = '__all__'

[Django]

#31546: Replace Command.requires_system_checks = True by something like
Command.required_system_checks = '__all__'
-+-
 Reporter:  Hasan Ramezani   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 Hasan Ramezani):

 * 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/067.8ac41deb07f5627f743024de72ad38e1%40djangoproject.com.

Re: [Django] #27686: calls to request.user.is_authenticated returns vary by cookie header for all users

[Django]

#27686: calls to request.user.is_authenticated returns vary by cookie header for
all users
-+-
 Reporter:  Jeff Willette|Owner:  Jeff
 |  Willette
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Szotten):

 yes, i was just reaching that conclusion myself. thanks, and apologies for
 the noise

-- 
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/069.3ea1e8827605de25d7efbdb9fb6b7e4c%40djangoproject.com.

Re: [Django] #31589: Raw queries do not work if any DB content column has the % symbol. (was: Raw queries do not work if any DB content column has the % symbol)

[Django]

#31589: Raw queries do not work if any DB content column has the % symbol.
-+-
 Reporter:  jotauses |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  raw query| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 My understanding is that you passed `titulo_infocor = "This is a test
 80%"`, this is not supported and moreover you’re at risk for SQL
 injection. Please check
 [https://docs.djangoproject.com/en/3.0/topics/db/sql/#passing-parameters-
 into-raw  Passing parameters into raw()] or use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] if you have further questions.

-- 
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/066.de4f776d2fe457eef4afa228034c0533%40djangoproject.com.

Re: [Django] #28263: TestCase breaks for databases that don't support savepoints

[Django]

#28263: TestCase breaks for databases that don't support savepoints
---+
 Reporter:  Lokesh Dokara  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 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 Tim Graham):

 * Attachment "28263.diff" added.


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

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

Re: [Django] #28263: TestCase breaks for databases that don't support savepoints

[Django]

#28263: TestCase breaks for databases that don't support savepoints
---+
 Reporter:  Lokesh Dokara  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.11
 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 Tim Graham):

 I'm attaching the patch that I used to fix this issue in a Django fork for
 CockroachDB. The most recent release, CockroachDB 20.1, adds support for
 savepoints, so this issue is no longer relevant 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4ff25640472c299426c3220cbecdabf4%40djangoproject.com.

Re: [Django] #31588: Unclear behaviour for ModelForms

[Django]

#31588: Unclear behaviour for ModelForms
-+-
 Reporter:  Vladislav|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  3.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  forms| Triage Stage:
 |  Unreviewed
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:

 Hi. Thanks for the report.

 The ''official decision'', the recommended way of doing it is to call
 `save()` with `commit=False`, then make your modifications before saving
 the instance finally.
 This is documented in
 [https://docs.djangoproject.com/en/3.0/topics/forms/modelforms/#the-save-
 method the save method docs]. See the example there of modifying an author
 in this way.

-- 
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/066.c82eb75ad80ea0fa1cdffdfe3a2baf1d%40djangoproject.com.

Re: [Django] #31582: Django template engine render pre-fetches data even when iterator() is used

[Django]

#31582: Django template engine render pre-fetches data even when iterator() is 
used
-+
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  3.0
 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 Carlton Gibson):

 Ah, I didn't properly read this bit:

 > context is pointing to the item which is the model itself! Even we fix
 above len() call somehow, this will hurt us again.

 There's an effort to allow a generator based approach to template
 rendering in #13910. There's a PR for that which got so far but needs
 pushing over the line.
 I don't know if that would solve second issues here...?

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

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

Re: [Django] #31582: Django template engine render pre-fetches data even when iterator() is used

[Django]

#31582: Django template engine render pre-fetches data even when iterator() is 
used
-+
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  3.0
 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:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Good follow up both, that's super!

 At first glance, certainly :),  consuming the iterator into a list isn't
 ideal.


 Question is, what can we do about it?

 The next line is:

 {{{
 len_values = len(values)
 }}}

 Then `len_values` is used to populate the various loop counter variables.
 `revcounter`, `last` and so on.

 I haven't thought it through but, I could see these possibly being made
 optional, maybe along the lines of adding an extra option like `reversed`?
 (It would require editing the `do_for()` function to parse another option.
 Not sure what it should be: ...`iterator`? )

 I think we'd have to call that a new feature. The behaviour isn't
 **incorrect**, it just uses more memory than we'd like in this case.

 Let's provisionally accept on that basis. It might be worth pinging the
 DevelopersMailingList to seek advice on how to proceed, particularly with
 regard to the possible API for such a change.

-- 
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/064.ab1354a14c87eddece1267afc30ae0d9%40djangoproject.com.

[Django] #31589: Raw queries do not work if any DB content column has the % symbol

[Django]

#31589: Raw queries do not work if any DB content column has the % symbol
-+-
   Reporter:  jotauses   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  raw query
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 **Only fails if any DB content column has the % symbol**.

 {{{
 query_postgresql = """SELECT *, similarity(titulo, '{0}') AS similarity
 FROM pdc_pdc  ORDER BY similarity DESC;"""

 pdc = Pdc.objects.raw(query_postgresql.format(titulo_infocor))
 }}}

 Column "titulo" content = "This is a test 80%".


 Traceback:

 {{{
   File "C:\Users\-\AppData\Local\Programs\Python\Python38-32\lib\site-
 packages\django\db\backends\utils.py", line 86, in _execute
 return self.cursor.execute(sql, params)
 IndexError: tuple index out of range
 }}}

-- 
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/051.705030b826d8262a76f7e06d39cf9d85%40djangoproject.com.

Re: [Django] #31582: Django template engine render pre-fetches data even when iterator() is used (was: Django template backend allocates model cache even iterator() is used)

[Django]

#31582: Django template engine render pre-fetches data even when iterator() is 
used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  3.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
-+--

-- 
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/064.6ab922693347aa4c11b61662ce37ae7d%40djangoproject.com.

[Django] #31588: Unclear behaviour for ModelForms

[Django]

#31588: Unclear behaviour for ModelForms
+
   Reporter:  Vladislav |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Forms |Version:  3.0
   Severity:  Normal|   Keywords:  forms
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I think it's very often task to add nessasary info to ModelForm before
 .save() and i suppose this must have official decision, not this
 workaround like answers in ticket:

 https://stackoverflow.com/questions/17126983/add-data-to-modelform-object-
 before-saving

-- 
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/051.3bae985626efd997dd65cee3e42cf91c%40djangoproject.com.

Re: [Django] #31587: Django admin - list_filter visually selected for query using implicit xx__id__exact

[Django]

#31587: Django admin - list_filter visually selected for query using implicit
xx__id__exact
---+--
 Reporter:  Anael Mobilia  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  3.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 Anael Mobilia):

 * Attachment "correct_result.png" added.

 Render of the correct result on the list filter

-- 
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/070.7cadf56a6034eb0e5b5ae0092d97819b%40djangoproject.com.

Re: [Django] #31587: Django admin - list_filter visually selected for query using implicit xx__id__exact

[Django]

#31587: Django admin - list_filter visually selected for query using implicit
xx__id__exact
---+--
 Reporter:  Anael Mobilia  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  3.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 Anael Mobilia):

 * Attachment "example.tar.xz" added.

 Example app

-- 
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/070.70fe375e148e2bc44563ebb6ee28c5e1%40djangoproject.com.

[Django] #31587: Django admin - list_filter visually selected for query using implicit xx__id__exact

[Django]

#31587: Django admin - list_filter visually selected for query using implicit
xx__id__exact
-+
   Reporter:  Anael Mobilia  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  3.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  |
-+
 Hello,

 As [https://docs.djangoproject.com/en/3.0/topics/db/queries/#the-pk-
 lookup-shortcut described on the documentation], there is implicit use of
 {{{
 xxx__id__exact
 }}}
 Equivalents are :
 {{{
 xxx_id# __exact is implied
 xxx_pk   # __pk implies __id__exact
 }}}

 Example app is in attachment.
 I generated a link on the contrib.admin (Country admin view) in order to
 be able to list all people living in a country.
 All the following links provides the same correct result (only people
 living on the country are displayed) :
 {{{
 url = 'Show
 inhabitants'
 url = 'Show
 inhabitants'
 url = 'Show
 inhabitants'
 }}}

 On the destination admin view (People), I have set a list_filter on
 Country.

 Only the first link select the currently filtered Country on the filter
 list (on the right of the screen on the People admin view), the two others
 links doesn't.

 As the last two selectors are shortcuts for the fully explicit form, I
 suggest to have the same render on the filter list (current value is
 selected/highlighted).

 Tested on Django 3.0.6.

 Regards

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

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

Re: [Django] #31524: Stop minifying only some admin static assets

[Django]

#31524: Stop minifying only some admin static assets
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   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:"9d211f149a8141a3990acae4cdada3875b9339b3" 9d211f1]:
 {{{
 #!CommitTicketReference repository=""
 revision="9d211f149a8141a3990acae4cdada3875b9339b3"
 Refs #31524 -- Moved release notes for
 81ffedaacc0d907b9feb73783edefdffd0ced606 to 3.2.
 }}}

-- 
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/067.6926a5b190938f732ca2d83ae49770a3%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  3.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 Sümer Cip):

 * status:  closed => new
 * 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/064.f2db058b17bb91c06d40a98c8fbd0651%40djangoproject.com.

[Django] #31586: Small mistake in 'Writing your first Django app, part 4' tutorial

[Django]

#31586: Small mistake in 'Writing your first Django app, part 4' tutorial
-+
   Reporter:  mikkac |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  master
   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  |
-+
 Hi, I found out that in one of code snippets, there is one mistake in
 `href` tag. I believe that instead of `'polls:detail'` it should be
 `'polls:vote'`. I'm talking about 'Vote again?' `href` in code below:
 {{{
 {{ question.question_text }}

 
 {% for choice in question.choice_set.all %}
 {{ choice.choice_text }} -- {{ choice.votes }} vote{{
 choice.votes|pluralize }}
 {% endfor %}
 

 Vote again?
 }}}

-- 
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/049.8dd64c4215002bbf8d37d61fb5dc18c9%40djangoproject.com.

Re: [Django] #31585: Translation: Part of tutorial02 to Korean. (was: Translation: Part of tutorial02 to Korean)

[Django]

#31585: Translation: Part of tutorial02 to Korean.
-+-
 Reporter:  flowertaekk-dev  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  translation  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

-- 
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/073.fa9d43820cd82fb44f8deb6043973235%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.0
 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
-+--

Comment (by Sümer Cip):

 And I think we should reopen 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/064.bdcf2735a47c9007cf42878cea38e1fc%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.0
 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
-+--

Comment (by Sümer Cip):

 Hi Keryn,

 I think you are exactly right about that:

 I traced memory allocation before/after that function call:

 {{{
 if not hasattr(values, '__len__'):
 print("render len enter", tracemalloc.get_traced_memory())
 values = list(values)
 print("render len exit", tracemalloc.get_traced_memory())
 '''
 render len enter (48421, 48653)
 render len exit (9390626, 9462231)
 '''
 }}}

 But we also have this afterwards in that function which complicates things
 more:

 {{{
 for node in self.nodelist_loop:
   nodelist.append(node.render_annotated(context))
 }}}

 {{{context}}} is pointing to the {{{item}}} which is the model itself!
 Even we fix above {{{len()}}} call somehow, this will hurt us again.

 I am not sure how to proceed further on this as this seems to require more
 internal Django knowledge than I have right now :)

 Any ideas?

-- 
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/064.45148fe09480349f8d2247efb298e84d%40djangoproject.com.

[Django] #31585: Translation: Part of tutorial02 to Korean

[Django]

#31585: Translation: Part of tutorial02 to Korean
-+-
   Reporter: |  Owner:  nobody
  flowertaekk-dev|
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  3.0
  Documentation  |
   Severity:  Normal |   Keywords:  translation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have found this part of tutorial02 has not been translated in Korean.
 So I would love to help for Korean to feel easier with this tutorial.

 original)

 The migrate command looks at the INSTALLED_APPS setting and creates any
 necessary database tables according to the database settings in your
 mysite/settings.py file and the database migrations shipped with the app
 (we'll cover those later). You'll see a message for each migration it
 applies. If you're interested, run the command-line client for your
 database and type \dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .schema
 (SQLite), or SELECT TABLE_NAME FROM USER_TABLES; (Oracle) to display the
 tables Django created.

 Korean)

 migration 커맨드는 INSTALLED_APPS를 확인한 후에 mysite/settings.py 파일의
 데이터베이스 설정을 이용해서 필요한 Database Table을 생성합니다. 그리고
 Database migration을 통해 생성된 결과물은 앱과 함께 제공됩니다(추후 살펴
 볼 예정). 위의 커맨드를 통해 Database migration이 적용되는 메시지를 확인할
 수 있습니다. 또한, 설정한 Database client을 실행하고 다음의 커맨드를 이용
 해서 Django가 생성한 Table들을 확인할 수 있습니다: \dt (PostgreSQL), SHOW
 TABLES; (MariaDB, MySQL), .schema (SQLite), or SELECT TABLE_NAME FROM
 USER_TABLES; (Oracle)

-- 
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/058.00a2bbabdad7b814ac6d137631cc50dc%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.0
 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
-+--

Comment (by Keryn Knight):

 If you can observe a difference between DTL & Jinja2, I'm inclined to
 think it's due to the `defaulttags.ForNode` implementation, and a
 ''potential'' candidate for the 'leak' would be:
 {{{
 if not hasattr(values, "__len__"):
 values = list(values)
 }}}

-- 
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/064.4281eba7a5ba01a6c9255448ab4a8130%40djangoproject.com.

Re: [Django] #31524: Stop minifying only some admin static assets

[Django]

#31524: Stop minifying only some admin static assets
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   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 Carlton Gibson ):

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


Comment:

 In [changeset:"81ffedaacc0d907b9feb73783edefdffd0ced606" 81ffeda]:
 {{{
 #!CommitTicketReference repository=""
 revision="81ffedaacc0d907b9feb73783edefdffd0ced606"
 Fixed #31524 -- Removed minified static assets from the admin.
 }}}

-- 
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/067.c8e7cadf4f69d35dff646362dfc697ca%40djangoproject.com.

Re: [Django] #31524: Stop minifying only some admin static assets

[Django]

#31524: Stop minifying only some admin static assets
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 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


-- 
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/067.cff8f3709db64441e64d60a99ad14da4%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  oracle exists| Triage Stage:  Ready for
  boolean|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"92acf1022fb13a7a8b1ff7cdfe72c21050c1e4e7" 92acf102]:
 {{{
 #!CommitTicketReference repository=""
 revision="92acf1022fb13a7a8b1ff7cdfe72c21050c1e4e7"
 [3.0.x] Fixed #31584 -- Fixed crash when chaining values()/values_list()
 after Exists() annotation and aggregation on Oracle.

 Oracle requires the EXISTS expression to be wrapped in a CASE WHEN in
 the GROUP BY clause.

 Regression in efa1908f662c19038a944129c81462485c4a9fe8.
 Backport of 3a941230c85b2702a5e1cd97e17251ce21057efa 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1e0947d91a803257d5af0df5422770ac%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  oracle exists| Triage Stage:  Ready for
  boolean|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"b46b0f80e81bbf8fcf7e8c20c249c8041db5e227" b46b0f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="b46b0f80e81bbf8fcf7e8c20c249c8041db5e227"
 [3.1.x] Fixed #31584 -- Fixed crash when chaining values()/values_list()
 after Exists() annotation and aggregation on Oracle.

 Oracle requires the EXISTS expression to be wrapped in a CASE WHEN in
 the GROUP BY clause.

 Regression in efa1908f662c19038a944129c81462485c4a9fe8.
 Backport of 3a941230c85b2702a5e1cd97e17251ce21057efa 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a66ce7d6a627f68bf5592f06ae66f2f2%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.0
 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
-+--

Comment (by Sümer Cip):

 Let me clarify this a bit more.

 I have modified {{{ModelIterable.__iter__}}} like following:

 {{{

 class ModelIterable(BaseIterable):
 """Iterable that yields a model instance for each row."""

 def __iter__(self):
 print("Enter ModelIterable.__iter__",
 tracemalloc.get_traced_memory())
 ...
 print("Leave ModelIterable.__iter__",
 tracemalloc.get_traced_memory())
 }}}

 Above code prints out the current used memory in that function + the peak
 memory reached.
 When I run it without using an {{{iterator()}}} call I get following
 values:

 {{{
 DTL no iterator (7K items)
 Enter ModelIterable.__iter__ (1340851, 1342301)
 Leave ModelIterable.__iter__ (5063404, 5063988)
 }}}

 Now, as you indicated this seems OK because the {{{Comment}}} object is
 created and its values initialized and cached. Let's see what happens if
 we run this with iterator:

 {{{
 DTL iterator (7K items)
 Enter ModelIterable.__iter__ (92488, 92995)
 Leave ModelIterable.__iter__ (5113261, 5219668)
 }}}

 Now, the memory usage and peak starts with a smaller value and somehow the
 memory usage+peak values go from 92KB to 5MB. We have confirmed from
 previous run that 5MB is the memory needed to hold the objects in cache.
 So, either memory is being cached somewhere or we are not freeing memory
 in this function.

 After returning from this function, the memory used+peak returns to
 normal, but we are peaking memory with the growth of items which should
 not be the case for {{{iterator()}}}, right?

 I have verified above code is working fine with Jinja2 engine. See the
 results:

 {{{
 Jinja2 no iterator (7K ITEMS)
 Enter ModelIterable.__iter__ (1362882, 1364332)
 Leave ModelIterable.__iter__ (5080351, 5080935)

 Jinja2 iterator (7K ITEMS)
 Enter ModelIterable.__iter__ (115616, 116123)
 Leave ModelIterable.__iter__ (878651, 1343215)
 }}}

 You can see that when iterator is being used, the memory usage numbers do
 not grow by a factor of 50. It is not reaching the value of 5080351 like
 we have in DTL.


 I am suspecting, somehow the loop in ModelIterable.__init__ is holding the
 reference somewhere else in DTL case, maybe?

 {{{
 for row in compiler.results_iter(results):
 obj = model_cls.from_db(db, init_list,
 row[model_fields_start:model_fields_end])
 
 }}}

-- 
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/064.da377257aae6afe276b31f83b97aada0%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  oracle exists| Triage Stage:  Ready for
  boolean|  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:"3a941230c85b2702a5e1cd97e17251ce21057efa" 3a94123]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a941230c85b2702a5e1cd97e17251ce21057efa"
 Fixed #31584 -- Fixed crash when chaining values()/values_list() after
 Exists() annotation and aggregation on Oracle.

 Oracle requires the EXISTS expression to be wrapped in a CASE WHEN in
 the GROUP BY clause.

 Regression in efa1908f662c19038a944129c81462485c4a9fe8.
 }}}

-- 
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/065.499d93b22ea02f72f2da4581cd7df68d%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle exists| Triage Stage:  Ready for
  boolean|  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/065.46ab18897a825199ba5b5a38b4939633%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle exists| Triage Stage:  Accepted
  boolean|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/12913 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/065.71ac67f80bc111d73985b05e3339d603%40djangoproject.com.

Re: [Django] #9107: URL arguments to set values of fields in admin don't work for inlines

[Django]

#9107: URL arguments to set values of fields in admin don't work for inlines
---+---
 Reporter:  josh@… |Owner:  TapanGujjar
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin inline   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Carlton Gibson):

 * needs_docs:  0 => 1
 * needs_tests:  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/075.d9165b689181bb95bce23e476e444110%40djangoproject.com.

Re: [Django] #9107: URL arguments to set values of fields in admin don't work for inlines

[Django]

#9107: URL arguments to set values of fields in admin don't work for inlines
---+---
 Reporter:  josh@… |Owner:  TapanGujjar
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin inline   | 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
 * 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/075.425006b066169c0f6298e8c36d8d066c%40djangoproject.com.

Re: [Django] #31582: Django template backend allocates model cache even iterator() is used

[Django]

#31582: Django template backend allocates model cache even iterator() is used
-+--
 Reporter:  Sümer Cip|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.0
 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 Carlton Gibson):

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


Comment:

 Hi. I'm not sure this is the right place (as yet) for this query.

 It seems like a usage question, rather than a specific bug reports, so I'd
 point you to TicketClosingReasons/UseSupportChannels.

 **Maybe** there's an issue there... if there's a concrete behaviour that's
 wrong but I can't see that from the report.

 > I see the django.db.models.base.Comment.__init__ caches the results.

 `QuerySet` has an internal results cache. `Model.__init__()` creates the
 instance in memory yes, but `ModelIterable` (which is what `.iterator()`
 gives you) instantiates the objects when you iterate it, so that's
 expected behaviour, independent of Jinja vs the DTL.

 If you can narrow this down to something specific that Django is doing
 wrong, we're very happy to have a look.

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

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

Re: [Django] #31034: Add a navigation sidebar to the admin

[Django]

#31034: Add a navigation sidebar to the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   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:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c9a9d042e5182cfb6c9aceaf292e5e3727f624dd" c9a9d042]:
 {{{
 #!CommitTicketReference repository=""
 revision="c9a9d042e5182cfb6c9aceaf292e5e3727f624dd"
 [3.1.x] Refs #31034 -- Documented admin requires
 django.template.context_processors.request.

 Required since d24ba1be7a53a113d19e2860c03aff9922efec24.

 Co-authored-by: Carlton Gibson 

 Backport of e341bed606d8ab2864838795276692cf86b08687 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.eddce0c90cb5888915f32ab2a870c5ce%40djangoproject.com.

Re: [Django] #31575: Document admin's requirement on django.template.context_processors.request context processor.

[Django]

#31575: Document admin's requirement on 
django.template.context_processors.request
context processor.
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 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:"1c2d0fdf3eb903d2323b39e0ca596e5322922a87" 1c2d0fd]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c2d0fdf3eb903d2323b39e0ca596e5322922a87"
 [3.1.x] Fixed #31575 -- Added system check for admin sidebar request
 context processor dependency.

 Co-authored-by: Carlton Gibson 

 Backport of d522b51c401429c169d88742178a9b3777903d9e 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c25124ce0986f88bd3ceb8e25bda005d%40djangoproject.com.

Re: [Django] #31575: Document admin's requirement on django.template.context_processors.request context processor.

[Django]

#31575: Document admin's requirement on 
django.template.context_processors.request
context processor.
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"d522b51c401429c169d88742178a9b3777903d9e" d522b51c]:
 {{{
 #!CommitTicketReference repository=""
 revision="d522b51c401429c169d88742178a9b3777903d9e"
 Fixed #31575 -- Added system check for admin sidebar request context
 processor dependency.

 Co-authored-by: Carlton Gibson 
 }}}

-- 
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/067.33d659c62730244b63b8f97d95642cac%40djangoproject.com.

Re: [Django] #31034: Add a navigation sidebar to the admin

[Django]

#31034: Add a navigation sidebar to the admin
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 |  Carrick
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   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:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e341bed606d8ab2864838795276692cf86b08687" e341bed6]:
 {{{
 #!CommitTicketReference repository=""
 revision="e341bed606d8ab2864838795276692cf86b08687"
 Refs #31034 -- Documented admin requires
 django.template.context_processors.request.

 Required since d24ba1be7a53a113d19e2860c03aff9922efec24.

 Co-authored-by: Carlton Gibson 
 }}}

-- 
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/065.61b016013f298dcfc862be1e1d7c49d7%40djangoproject.com.

Re: [Django] #30715: ArrayField lookups crash on ArrayAgg() over AutoFields.

[Django]

#30715: ArrayField lookups crash on ArrayAgg() over AutoFields.
-+-
 Reporter:  NyanKiyoshi  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  array, serial,   | Triage Stage:  Ready for
  postgres, psql, auto, id   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => fixed


Comment:

 The issue has been present since the feature was introduced. Per our
 backporting policy this means it doesn't qualify for a backport to 2.2.x
 anymore.
 See https://docs.djangoproject.com/en/dev/internals/release-process/ for
 more details.

-- 
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/069.19e412926d3018b788422d37591726ad%40djangoproject.com.

Re: [Django] #27686: calls to request.user.is_authenticated returns vary by cookie header for all users

[Django]

#27686: calls to request.user.is_authenticated returns vary by cookie header for
all users
-+-
 Reporter:  Jeff Willette|Owner:  Jeff
 |  Willette
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 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 Carlton Gibson):

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


Comment:

 Hi David.

 As I read the discussion, the issue is that the `is_authenticated()` check
 could return `True`, i.e. if there's any point in checking it at all, then
 we really **should** set the `Vary` header.
 (Hence the ticket being closed as invalid.)

 This is independent of whether there's a way we could detect this without
 triggering it being set, which would be to introduce a regression on this
 understanding.

 Please see the
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/ Triage Flow guidelines] and
 TicketClosingReasons/DontReopenTickets — if there's doubt about a
 resolution, much better that it's addressed on the DevelopersMailingList
 where it can be properly discussed. Thanks.

-- 
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/069.4605d17d9a78242fbfdd7052565d1a55%40djangoproject.com.

Re: [Django] #30715: ArrayField lookups crash on ArrayAgg() over AutoFields.

[Django]

#30715: ArrayField lookups crash on ArrayAgg() over AutoFields.
-+-
 Reporter:  NyanKiyoshi  |Owner:  felixxm
 Type:  Bug  |   Status:  new
Component:  contrib.postgres |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  array, serial,   | Triage Stage:  Ready for
  postgres, psql, auto, id   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ivan Piskunov):

 * status:  closed => new
 * version:  master => 2.2
 * resolution:  fixed =>


Comment:

 Hi felixxm, sorry to tell, but this issue still present in Django 2.2.12
 and 2.2.x branch as well.
 Also it does not affect only `pk` fields, but at least `ForeignKey` too.
 Could you please apply your fix to 2.2?

-- 
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/069.a1bb8fd0a2bb62252fc6c3700c1d6a91%40djangoproject.com.

Re: [Django] #31575: Document admin's requirement on django.template.context_processors.request context processor.

[Django]

#31575: Document admin's requirement on 
django.template.context_processors.request
context processor.
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 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:  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/067.0d7c2517c10340d10db857a1d19b0fb7%40djangoproject.com.

Re: [Django] #31568: Alias used in aggregate filtering is incorrect.

[Django]

#31568: Alias used in aggregate filtering is incorrect.
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 felixxm):

 Replying to [comment:4 Simon Charette]:
 > Submitted a patch but we should also fix `Subquery.__eq__` which was
 broken by 691def10a0197d83d2d108bd9043b0916d0f09b4. Right now
 `Subquery(qs1) == Subquery(qs2)`.

 I will create a separate issue for 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/064.cc0340e59feedf9ec5c7d686976337c9%40djangoproject.com.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"49bbf6570d9f0880b836f741d79e4cdb6e061ea2" 49bbf657]:
 {{{
 #!CommitTicketReference repository=""
 revision="49bbf6570d9f0880b836f741d79e4cdb6e061ea2"
 [3.0.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.199dd4271798c985191d71b844b8ca1b%40djangoproject.com.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3913acdb29d09109ec82ce789b592e6281aa7be9" 3913acdb]:
 {{{
 #!CommitTicketReference repository=""
 revision="3913acdb29d09109ec82ce789b592e6281aa7be9"
 [3.1.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.e78de1b23d2adde513092b0a56091e3d%40djangoproject.com.

Re: [Django] #30727: Pickling a QuerySet evaluates the querysets given to Subquery in annotate.

[Django]

#30727: Pickling a QuerySet evaluates the querysets given to Subquery in 
annotate.
-+-
 Reporter:  Andrew Brown |Owner:  Andrew
 |  Brown
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"adfbf653dc1c1d0e0dacc4ed46602d22ba28b004" adfbf653]:
 {{{
 #!CommitTicketReference repository=""
 revision="adfbf653dc1c1d0e0dacc4ed46602d22ba28b004"
 Fixed #31568 -- Fixed alias reference when aggregating over multiple
 subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus 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/065.7258a59956a6e24abef3d94494cf1a93%40djangoproject.com.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"adfbf653dc1c1d0e0dacc4ed46602d22ba28b004" adfbf653]:
 {{{
 #!CommitTicketReference repository=""
 revision="adfbf653dc1c1d0e0dacc4ed46602d22ba28b004"
 Fixed #31568 -- Fixed alias reference when aggregating over multiple
 subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus 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/070.da9dd92212bd51e19f5cfff166dfdc95%40djangoproject.com.

Re: [Django] #31568: Alias used in aggregate filtering is incorrect.

[Django]

#31568: Alias used in aggregate filtering is incorrect.
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"49bbf6570d9f0880b836f741d79e4cdb6e061ea2" 49bbf657]:
 {{{
 #!CommitTicketReference repository=""
 revision="49bbf6570d9f0880b836f741d79e4cdb6e061ea2"
 [3.0.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.c511bf781797cf08c9a74c5904aa5ad2%40djangoproject.com.

Re: [Django] #30727: Pickling a QuerySet evaluates the querysets given to Subquery in annotate.

[Django]

#30727: Pickling a QuerySet evaluates the querysets given to Subquery in 
annotate.
-+-
 Reporter:  Andrew Brown |Owner:  Andrew
 |  Brown
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"49bbf6570d9f0880b836f741d79e4cdb6e061ea2" 49bbf657]:
 {{{
 #!CommitTicketReference repository=""
 revision="49bbf6570d9f0880b836f741d79e4cdb6e061ea2"
 [3.0.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bf463dd65850a0d01488f08e69d911da%40djangoproject.com.

Re: [Django] #31568: Alias used in aggregate filtering is incorrect.

[Django]

#31568: Alias used in aggregate filtering is incorrect.
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"3913acdb29d09109ec82ce789b592e6281aa7be9" 3913acdb]:
 {{{
 #!CommitTicketReference repository=""
 revision="3913acdb29d09109ec82ce789b592e6281aa7be9"
 [3.1.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9cb89849b6e2418f242890640d55a9ae%40djangoproject.com.

Re: [Django] #31568: Alias used in aggregate filtering is incorrect.

[Django]

#31568: Alias used in aggregate filtering is incorrect.
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"adfbf653dc1c1d0e0dacc4ed46602d22ba28b004" adfbf653]:
 {{{
 #!CommitTicketReference repository=""
 revision="adfbf653dc1c1d0e0dacc4ed46602d22ba28b004"
 Fixed #31568 -- Fixed alias reference when aggregating over multiple
 subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus 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/064.2a55e3043de11847dfe74aca93fa50ce%40djangoproject.com.

Re: [Django] #30727: Pickling a QuerySet evaluates the querysets given to Subquery in annotate.

[Django]

#30727: Pickling a QuerySet evaluates the querysets given to Subquery in 
annotate.
-+-
 Reporter:  Andrew Brown |Owner:  Andrew
 |  Brown
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

 In [changeset:"3913acdb29d09109ec82ce789b592e6281aa7be9" 3913acdb]:
 {{{
 #!CommitTicketReference repository=""
 revision="3913acdb29d09109ec82ce789b592e6281aa7be9"
 [3.1.x] Fixed #31568 -- Fixed alias reference when aggregating over
 multiple subqueries.

 691def10a0197d83d2d108bd9043b0916d0f09b4 made all Subquery() instances
 equal to each other which broke aggregation subquery pushdown which
 relied on object equality to determine which alias it should select.

 Subquery.__eq__() will be fixed in an another commit but
 Query.rewrite_cols() should haved used object identity from the start.

 Refs #30727, #30188.

 Thanks Makina Corpus for the report.

 Backport of adfbf653dc1c1d0e0dacc4ed46602d22ba28b004 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c35d9307e5918abc445c2ebb10fddfce%40djangoproject.com.

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  feature test models  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Ahmad Abdallah):

 Your solution is indeed less magic and much more isolated; reusing
 automatic model discovery from appConfig makes a lot more sense than
 attempting load them manually.

 This will be a nice feature to have for 3.2.

 The manual secondary migrations for models referenced outside of the test
 app seems like a fair cost to get models inside tests, and from my
 understanding, the test models are meant to be self-contained i.e models
 created purely for tests that will reference each other only so it
 shouldn't be much of an 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/066.b882090ea61a4ff865261f4598c04784%40djangoproject.com.

Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

[Django]

#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (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:"afceb2241ba84dfafe59de326cdc9c01963ddefb" afceb22]:
 {{{
 #!CommitTicketReference repository=""
 revision="afceb2241ba84dfafe59de326cdc9c01963ddefb"
 [3.0.x] Fixed #31566 -- Fixed aliases crash when chaining
 values()/values_list() after annotate() with aggregations and subqueries.

 Subquery annotation references must be resolved if they are excluded
 from the GROUP BY clause by a following .values() call.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.

 Thanks Makina Corpus for the report.

 Backport of 42c08ee46539ef44f8658ebb1cbefb408e0d03fe 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a6fcd88cf0ad25b0c83ffe58ea3ca779%40djangoproject.com.

Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

[Django]

#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (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:"8cb87a3f7c413b9943a5a73e156716067267b182" 8cb87a3f]:
 {{{
 #!CommitTicketReference repository=""
 revision="8cb87a3f7c413b9943a5a73e156716067267b182"
 [3.1.x] Fixed #31566 -- Fixed aliases crash when chaining
 values()/values_list() after annotate() with aggregations and subqueries.

 Subquery annotation references must be resolved if they are excluded
 from the GROUP BY clause by a following .values() call.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.

 Thanks Makina Corpus for the report.

 Backport of 42c08ee46539ef44f8658ebb1cbefb408e0d03fe 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.5d2a007526915e624b553fcadc94bd2b%40djangoproject.com.

Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

[Django]

#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (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:"42c08ee46539ef44f8658ebb1cbefb408e0d03fe" 42c08ee4]:
 {{{
 #!CommitTicketReference repository=""
 revision="42c08ee46539ef44f8658ebb1cbefb408e0d03fe"
 Fixed #31566 -- Fixed aliases crash when chaining values()/values_list()
 after annotate() with aggregations and subqueries.

 Subquery annotation references must be resolved if they are excluded
 from the GROUP BY clause by a following .values() call.

 Regression in fb3f034f1c63160c0ff13c609acd01c18be12f80.

 Thanks Makina Corpus 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/064.74aea8a6df9f9e889a7ccb29126a09ef%40djangoproject.com.

Re: [Django] #31584: Queryset crashes when grouping by Exists() on Oracle. (was: Queryset crashes when gruping by Exists() on Oracle.)

[Django]

#31584: Queryset crashes when grouping by Exists() on Oracle.
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle exists| Triage Stage:  Accepted
  boolean|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #31577: The explanation ended in the middle.

[Django]

#31577: The explanation ended in the middle.
-+-
 Reporter:  Joon Hwan 김준환 |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

 A PR clarifying would be very welcome. Please assign yourself and reopen
 the ticket if you will provide one. Thanks!

-- 
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/063.8ba7108c0e99d7c54d1f4ecf60d0acb9%40djangoproject.com.

Re: [Django] #31566: Subquery in annotation is included by its alias and is not present in the SELECT

[Django]

#31566: Subquery in annotation is included by its alias and is not present in 
the
SELECT
-+-
 Reporter:  Gagaro   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (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 felixxm):

 * 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/064.28ba706220f4392b842645c36c3ad541%40djangoproject.com.

[Django] #31584: Queryset crashes when gruping by Exists() on Oracle.

[Django]

#31584: Queryset crashes when gruping by Exists() on Oracle.
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Release|   Keywords:  oracle exists
  blocker|  boolean
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Boolean expressions are not supported in the GROUP_BY clause on Oracle.
 Noticed when polishing [https://github.com/django/django/pull/12911 PR].

 Regression in efa1908f662c19038a944129c81462485c4a9fe8.

-- 
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/050.9ddee26f4a3ee7fa8bc00e52e4f4275e%40djangoproject.com.