Re: [Django] #30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell database shell.

[Django]

#30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell 
database
shell.
-+-
 Reporter:  Simon Charette   |Owner:  Farhaan
 Type:   |  Bukhsh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell database | Triage Stage:  Accepted
  options|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Farhaan Bukhsh):

 Replying to [comment:5 Simon Charette]:
 > > I was thinking something similar may be a list of all options which is
 not passed near the dbshell documentation. What do you think?
 >
 > I think it will be hard to come up with this list for all backends and
 maintain it over time as some of them are directly passed to the
 underlying connector.

 So I can just link dbshell with DATABASE_OPTIONS pointing out that some
 options might be ignored

-- 
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.c1ad31e715c709159ce9348383631366%40djangoproject.com.

Re: [Django] #30256: autocomplete_fields cause one or two extra queries for each field wth foreign key or many to many relation

[Django]

#30256: autocomplete_fields cause one or two extra queries for each field wth
foreign key or many to many relation
--+
 Reporter:  George Tantiras   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  autocomplete  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 The server side cursor (`DECLARE CURSOR`) get created when using
 `iterator` on PostgreSQL; the SQLite backend doesn't support this feature.

 The only internal use of `.iterator()` I can think of is in
 `ModelChoiceIterator.choice`
 
([https://github.com/django/django/blob/2847d2c760438195c4c71ea9d3fded1ce116ea4e/django/forms/models.py#L1128-L1141
 link]) if that can be of any help.

-- 
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.bb09140fb79d63bdbfcb34c68ab1adb7%40djangoproject.com.

Re: [Django] #30256: autocomplete_fields cause one or two extra queries for each field wth foreign key or many to many relation

[Django]

#30256: autocomplete_fields cause one or two extra queries for each field wth
foreign key or many to many relation
--+
 Reporter:  George Tantiras   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  autocomplete  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by George Tantiras):

 I cannot reproduce the issue using PostgreSQL-11.5.

 Currently, Django Debug Toolbar reports the same number of queries when
 using dal3, django-autocomplete or "no autocomplete".

 However, there is a difference:

 * When using dal3 or "no autocomplete" a query appears (it was not present
 when I reported this issue):


 {{{
 DECLARE "_django_curs_140333492991744_3" NO SCROLL CURSOR WITH HOLD FOR
 SELECT ••• FROM "inlines_master" WHERE "inlines_master"."id" IN (1)
 }}}


 * Django autocomplete reatains its behaviour, it does not produce the
 above query rather than a proper SELECT as expected (the reason for
 reporting this issue):

 {{{
 SELECT ••• FROM "inlines_master" WHERE "inlines_master"."id" IN (1)
 }}}

 Is there something right happening or something wrong?

-- 
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.2979b7cd16a06237080ab316156266f7%40djangoproject.com.

Re: [Django] #29919: Using RelatedOnlyFieldListFilter with reverse ManyToMany crashes

[Django]

#29919: Using RelatedOnlyFieldListFilter with reverse ManyToMany crashes
---+
 Reporter:  Dan Moore  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  2.1
 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 Tim Graham):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 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.0e29a68194afcf112f22de3cfd1ef0f1%40djangoproject.com.

[Django] #30899: Lazily compile large regular expressions

[Django]

#30899: Lazily compile large regular expressions
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  Cleanup/optimization   | Status:  new
  Component:  Core (Other)   |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  |
-+
 Inspired by [this article from Instagram](https://instagram-
 engineering.com/python-at-scale-strict-modules-c0bb9245c834)

 Currently Django lazily compiles some regular expressions such as those in
 validators:
 
https://github.com/django/django/blob/54ea290e5bbd19d87bd8dba807738eeeaf01a362/django/core/validators.py#L17

 This is to save on import time.

 There are other import-time `re.compile` calls throughout the codebase,
 these could be migrated to lazy regex compiles to save on their import
 time:

 https://github.com/django/django/search?q=re.compile_q=re.compile

-- 
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/053.bf110d6abc1af114ae1c9e3b503060f2%40djangoproject.com.

Re: [Django] #24203: Optimisation: adding multiple fields to same model should attempt to run single ALTER TABLE statement

[Django]

#24203: Optimisation: adding multiple fields to same model should attempt to run
single ALTER TABLE statement
-+-
 Reporter:  Peter Lauri  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  migration| 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 Phil Krylov):

 * cc: Phil Krylov (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/068.09cf0cec6cdb93c58ee794e74851fa78%40djangoproject.com.

Re: [Django] #24363: Combine ALTER TABLE .. MODIFY statements for multiple columns into one statement.

[Django]

#24363: Combine ALTER TABLE .. MODIFY statements for multiple columns into one
statement.
-+-
 Reporter:  slachinger   |Owner:
 |  ambivalentno
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  Modify Field Column  | 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 Phil Krylov):

 * cc: Phil Krylov (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/068.4f81e81b0261674e46b191d1ec42aff5%40djangoproject.com.

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 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 Simon Charette):

 I think this should be addressed, it doesn't make much sense that
 `related_query_name` is used everywhere but in `prefetch_related`. It was
 probably simply overlooked in `prefetch_related` given it works in
 `select_related`.

 It should not be too hard to deprecate given the rare usages of
 `related_query_name` by accepting both `related_query_name` and
 `related_name` during the deprecation period and warning when
 `related_name != related_query_name` and `related_name` is used.

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

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

Re: [Django] #30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell database shell.

[Django]

#30865: Document that some DATABASES['OPTIONS'] are not passed to dbshell 
database
shell.
-+-
 Reporter:  Simon Charette   |Owner:  Farhaan
 Type:   |  Bukhsh
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell database | Triage Stage:  Accepted
  options|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 > I was thinking something similar may be a list of all options which is
 not passed near the dbshell documentation. What do you think?

 I think it will be hard to come up with this list for all backends and
 maintain it over time as some of them are directly passed to the
 underlying connector.

-- 
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.05f375ceb2c1cbabaf4b8999afa13e00%40djangoproject.com.

Re: [Django] #29926: Python 3.8 compatibility

[Django]

#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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 Mariusz Felisiak ):

 In [changeset:"753a34b42ae2f24536dbfe37dda8d71a992eca5c" 753a34b4]:
 {{{
 #!CommitTicketReference repository=""
 revision="753a34b42ae2f24536dbfe37dda8d71a992eca5c"
 [3.0.x] Refs #29926 -- Skipped
 RemoteTestResultTest.test_add_failing_subtests() on Python 3.8+ and tblib
 <= 1.4.0.

 Backport of 2847d2c760438195c4c71ea9d3fded1ce116ea4e 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.4efa93fdce60b0cc9127ca18d4912bb9%40djangoproject.com.

Re: [Django] #29926: Python 3.8 compatibility

[Django]

#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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 GitHub ):

 In [changeset:"2847d2c760438195c4c71ea9d3fded1ce116ea4e" 2847d2c7]:
 {{{
 #!CommitTicketReference repository=""
 revision="2847d2c760438195c4c71ea9d3fded1ce116ea4e"
 Refs #29926 -- Skipped RemoteTestResultTest.test_add_failing_subtests() on
 Python 3.8+ and tblib <= 1.4.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/067.b338c272e58fc93a137c4beef41eba83%40djangoproject.com.

Re: [Django] #30827: bulk_create batch_size param overrides the compatible batch size calculation

[Django]

#30827: bulk_create batch_size param overrides the compatible batch size
calculation
-+-
 Reporter:  Ahmet Kucuk  |Owner:  Ahmet
 |  Kucuk
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Chetan Khanna):

 Glad :)

-- 
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/068.c1d36f6c5350e8dab0fae62916bb2e77%40djangoproject.com.

Re: [Django] #13724: Calling QuerySet.delete() through a relation the DB router is ignored.

[Django]

#13724: Calling QuerySet.delete() through a relation the DB router is ignored.
-+-
 Reporter:  Chris Targett|Owner:  Paul
|  Collins
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  multidb  | Triage Stage:  Accepted
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:"43bc59ceb624d6a1ac58aa7a282254e60c9c4025" 43bc59ce]:
 {{{
 #!CommitTicketReference repository=""
 revision="43bc59ceb624d6a1ac58aa7a282254e60c9c4025"
 [2.2.x] Refs #13724 -- Corrected QuerySet signature in docs.

 Backport of 6c23b43655f3710cfb1ecc57236405d11a544247 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/090.778fcd1b0b9e7d2318c9591e5f02%40djangoproject.com.

Re: [Django] #13724: Calling QuerySet.delete() through a relation the DB router is ignored.

[Django]

#13724: Calling QuerySet.delete() through a relation the DB router is ignored.
-+-
 Reporter:  Chris Targett|Owner:  Paul
|  Collins
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  multidb  | Triage Stage:  Accepted
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:"6c23b43655f3710cfb1ecc57236405d11a544247" 6c23b436]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c23b43655f3710cfb1ecc57236405d11a544247"
 Refs #13724 -- Corrected QuerySet signature in docs.
 }}}

-- 
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/090.8a17ba8395e28c7679e7b3d42031ffdf%40djangoproject.com.

Re: [Django] #13724: Calling QuerySet.delete() through a relation the DB router is ignored.

[Django]

#13724: Calling QuerySet.delete() through a relation the DB router is ignored.
-+-
 Reporter:  Chris Targett|Owner:  Paul
|  Collins
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  multidb  | Triage Stage:  Accepted
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:"213a39b4df1edb36b042e347a6c344b3fcd27bc0" 213a39b4]:
 {{{
 #!CommitTicketReference repository=""
 revision="213a39b4df1edb36b042e347a6c344b3fcd27bc0"
 [3.0.x] Refs #13724 -- Corrected QuerySet signature in docs.

 Backport of 6c23b43655f3710cfb1ecc57236405d11a544247 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/090.332c644167bea68d81e99a177f651258%40djangoproject.com.

Re: [Django] #29926: Python 3.8 compatibility

[Django]

#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  felixxm
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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 felixxm):

 * owner:  nobody => felixxm
 * 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.4269bc662c15bfa4c5a4ebac09fceaf5%40djangoproject.com.

Re: [Django] #29926: Python 3.8 compatibility

[Django]

#29926: Python 3.8 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 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 felixxm):

 * stage:  Someday/Maybe => 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/067.c162bc39fe96d7099349d33a7e666c9d%40djangoproject.com.

Re: [Django] #13750: ImageField accessing height or width and then data results in "I/O operation on closed file"

[Django]

#13750: ImageField accessing height or width and then data results in "I/O
operation on closed file"
--+
 Reporter:  ROsborne  |Owner:  Aksel
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 [https://github.com/django/django/pull/11912 Docs 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/066.22e840f6ae3f57d09ca73cd29e6ce10b%40djangoproject.com.

Re: [Django] #30252: ImageField's to_python() stores reference to closed Image object

[Django]

#30252: ImageField's to_python() stores reference to closed Image object
-+-
 Reporter:  Felix Dreissig   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1
 * version:  2.1 => 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/061.baada251a40fe963533f164a7a8647c5%40djangoproject.com.

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 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 Adam Sołtysik):

 This only explains why it was easier to implement that way, but doesn't
 prove it shouldn't work the other way. I started using
 `prefetch_related()` instead of `select_related()` when I found out that
 it is much faster with `LIMIT`ed queries (at least on PostgreSQL). The
 fact that I had to change relation names was a bit confusing. But if you
 don't think this should be changed, then so be it.

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

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

Re: [Django] #30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and PostgreSQL. (was: Improved QuerySet.explain() for newer versions of MariaDB and MySQL.)

[Django]

#30897: Improved QuerySet.explain() for newer versions of MariaDB, MySQL and
PostgreSQL.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  explain, analyze,| Triage Stage:  Accepted
  mariadb, mysql, postgresql |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * keywords:  explain, analyze, mariadb, mysql => explain, analyze, mariadb,
 mysql, postgresql


Old description:

> - MySQL 8.0.16+ has support for
> [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-execution-
> plan EXPLAIN FORMAT=TREE].
> - MySQL 8.0.18+ has support for
> [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
> EXPLAIN ANALYZE].
> - MariaDB 10.1.0+ has support for [https://mariadb.com/kb/en/library
> /analyze-statement/ ANALYZE]. (Was `EXPLAIN ANALYZE` before 10.1.0.)

New description:

 - MySQL 8.0.16+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-execution-
 plan EXPLAIN FORMAT=TREE].
 - MySQL 8.0.18+ has support for
 [https://dev.mysql.com/doc/refman/8.0/en/explain.html#explain-analyze
 EXPLAIN ANALYZE].
 - MariaDB 10.1.0+ has support for [https://mariadb.com/kb/en/library
 /analyze-statement/ ANALYZE]. (Was `EXPLAIN ANALYZE` before 10.1.0.)
 - PostgreSQL 12+ has support for a new [https://www.postgresql.org/docs/12
 /sql-explain.html#SQL-EXPLAIN SETTINGS] option to `EXPLAIN`.

--

-- 
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.443cb4be130c6194f75f6e3dcab6dac1%40djangoproject.com.

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 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):

 Well, they're not really the same thing... `prefetch_related()` is
 intended for ''Many'' relations, not one-to-one, and it first of all needs
 to pick the related object descriptor off of the model in order to build
 the right queryset, for the follow-up query. Thus it needs an actual
 attribute on the model.

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

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

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 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 Adam Sołtysik):

 I think the related_query_name docs are clear enough that setting it
 overrides the name of the reverse filter, and that a clarification in the
 select_related() docs would only muddy the waters for the majority of
 users.

 OK, but why doesn't it override the name of the reverse filter in the case
 of `prefetch_related()` then? My report is about the inconsistency between
 `select_related()` and `prefetch_related()`. I want to use different
 `related_name` and `related_query_name` in my models and I would expect
 that `related_query_name` can be used in both `select_related()` and
 `prefetch_related()`.

-- 
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.55341604f69725b1f5f8631f46b444a2%40djangoproject.com.

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 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 Carlton Gibson):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Database layer (models, ORM) => Documentation
 * type:  Bug => Cleanup/optimization


Comment:

 OK, yes. Your models work the same. It's the presence of the
 `related_query_name` which causes the failure. Remove it and it works,
 because (as per the docs) `related_query_name` defaults to `related_name`
 if that's set.

 At best this is a documentation cleanup/optimization **but** setting
 `related_query_name` explicitly is an much more specialised use case than
 setting `related_name`. I think the `related_query_name` docs are clear
 enough that setting it overrides the name of the reverse filter, and that
 a ''clarification'' in the `select_related()` docs would only muddy the
 water for the majority of users. (One should under the consequences before
 setting `related_query_name`.)

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

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

Re: [Django] #30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name`

[Django]

#30894: Reverse OneToOneField relation: `prefetch_related` uses `related_name`
while `select_related` uses `related_query_name`
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hi Adam.

 It looks to me as if this case is already covered by the test suite (and
 works)...

 We have a
 
[https://github.com/django/django/blob/af8dbbe0d5099ce09fc77abdf8a3fb8a4f4015d9/tests/select_related_onetoone/models.py#L97-L103
 LinkedList model]:


 {{{
 class LinkedList(models.Model):
 name = models.CharField(max_length=50)
 previous_item = models.OneToOneField(
 'self', models.CASCADE,
 related_name='next_item',
 blank=True, null=True,
 )
 }}}

 This is using the `related_name` `'next_item'`.

 Then
 
[https://github.com/django/django/blob/af8dbbe0d5099ce09fc77abdf8a3fb8a4f4015d9/tests/select_related_onetoone/tests.py#L209-L214
 in the test case, we use that in `select_related`]:

 {{{
 def test_self_relation(self):
 item1 = LinkedList.objects.create(name='item1')
 LinkedList.objects.create(name='item2', previous_item=item1)
 with self.assertNumQueries(1):
 item1_db =
 LinkedList.objects.select_related('next_item').get(name='item1')
 self.assertEqual(item1_db.next_item.name, 'item2')
 }}}

-- 
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.6d0e31f01ad09168d619b1fc8db05f6f%40djangoproject.com.

Re: [Django] #30895: Multiples trailing slashes appended to URL

[Django]

#30895: Multiples trailing slashes appended to URL
--+--
 Reporter:  Conor Cunningham  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (URLs)   |  Version:  2.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:  urls, url | 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 Conor.

 I think this is a mis-understanding on your part here. Alas, it's not
 something we can address directly on the issue tracker. See
 TicketClosingReasons/UseSupportChannels, which I know is where you began…

 `APPEND_SLASH` does not affect the available URLs. Rather it tries an
 additional request to the same URL (if it's missing a slash) to see if
 that matches. Docs for `APPEND_SLASH`.

 > When set to True, if the request URL does not match any of the patterns
 in the URLconf and it doesn’t end in a slash, an HTTP redirect is issued
 to the same URL with a slash appended.

 So I'd try `api/v1/case`, get a 404 and be redirected to `api/v1/case/` to
 give that a chance to match.

 See the docs for [https://docs.djangoproject.com/en/2.2/topics/http/urls
 #including-other-urlconfs Including other URLconfs] to get your
 configuration correct. Note the examples look like this:


 {{{
 from django.urls import include, path

 urlpatterns = [
 # ... snip ...
 path('community/', include('aggregator.urls')),
 path('contact/', include('contact.urls')),
 # ... snip ...
 ]
 }}}

 i.e. they do include the trailing slash when using `include()`.

 (From your screenshot, I'd guess `api/v1case` would match, but that's not
 what you're intending...)

 Good luck.

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

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

Re: [Django] #21961: Add support for database-level cascading options

[Django]

#21961: Add support for database-level cascading options
-+-
 Reporter:  Christophe Pettus|Owner:  Nick
 |  Stefan
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Stefan):

 * cc: Nick Stefan (added)
 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8661 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/061.39e6d67bb81119c68fd44284731b1d17%40djangoproject.com.