Re: [Django] #30020: Support reading null values for numeric fields on Shapefile import via LayerMapping

[Django]

#30020: Support reading null values for numeric fields on Shapefile import via
LayerMapping
-+-
 Reporter:  Kathryn Killebrew|Owner:  Kathryn
 |  Killebrew
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GEOS,   | Triage Stage:  Ready for
  LayerMapping   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

[Django]

#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Accepted
  returning, default, model, field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 You should be able to trigger the Oracle build yourself as described on
 wiki:Jenkins. I ran the tests locally and put the failures in a PR
 comment.

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

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

Re: [Django] #29444: Allow fields to be part of the RETURNING clause during INSERT

[Django]

#29444: Allow fields to be part of the RETURNING clause during INSERT
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 Type:   |  Hoppe
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Accepted
  returning, default, model, field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b131f9c79f3284f7220c65ceb9125ba4278dc0a4" b131f9c7]:
 {{{
 #!CommitTicketReference repository=""
 revision="b131f9c79f3284f7220c65ceb9125ba4278dc0a4"
 Refs #29444 -- Renamed DatabaseFeatures.can_return_id* to be generic for
 other columns.
 }}}

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

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

Re: [Django] #30146: Move fieldset toggle to the right

[Django]

#30146: Move fieldset toggle to the right
-+-
 Reporter:  Pascal Polleunus |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 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:  1
-+-

Comment (by Pascal Polleunus):

 I think that from a UX point of view, the expand/collapse toggle is better
 located on the right… and usually is.
 The text "show/hide" could also be replaced with "+/-" or "▼/▲).

 PS: Sorry, I initially planned to submit a patch but then didn't ;-)

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

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

Re: [Django] #30146: Move fieldset toggle to the right

[Django]

#30146: Move fieldset toggle to the right
-+-
 Reporter:  Pascal Polleunus |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 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:  1
-+-
Changes (by Pascal Polleunus):

 * Attachment "admin-toggle-proposal.png" added.


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

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

Re: [Django] #30146: Move fieldset toggle to the right

[Django]

#30146: Move fieldset toggle to the right
-+-
 Reporter:  Pascal Polleunus |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 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:  1
-+-
Changes (by Tim Graham):

 * has_patch:  1 => 0
 * easy:  1 => 0


Comment:

 Can you explain the why? Some screenshots would be useful.

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

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

[Django] #30146: Move fieldset toggle to the right

[Django]

#30146: Move fieldset toggle to the right
+
   Reporter:  Pascal Polleunus  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  1 |
+
 Basically…
 In
 
[https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/collapse.js
 collapse.js],  remove lines 28 and 30.
 In
 
[https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css
 forms.css], for `fieldset .collapse-toggle`, add `float: right;` after
 line 233.

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

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

Re: [Django] #30076: get_FOO_display missing if field choices is specified but falsey

[Django]

#30076: get_FOO_display missing if field choices is specified but falsey
-+-
 Reporter:  Joshua Cannon|Owner:  Joshua
 |  Cannon
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  choices  | Triage Stage:  Accepted
  get_FOO_display|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"16a5a2a2c8d8dbf9cc3e033dd84b986bcaadb963" 16a5a2a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="16a5a2a2c8d8dbf9cc3e033dd84b986bcaadb963"
 Fixed #30076 -- Added Model.get_FOO_display() even if field's choices are
 empty.
 }}}

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

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

Re: [Django] #30091: Incorrect middleware ordering allows invalid HTTP_HOST header to cause CsrfViewMiddleware failure when using CSRF_USE_SESSIONS.

[Django]

#30091: Incorrect middleware ordering allows invalid HTTP_HOST header to cause
CsrfViewMiddleware failure when using CSRF_USE_SESSIONS.
-+-
 Reporter:  Mark Gregson |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  middleware   | 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 ):

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


Comment:

 In [changeset:"89d39dc1d77338b7436abec017e392fc1bdbe3d7" 89d39dc]:
 {{{
 #!CommitTicketReference repository=""
 revision="89d39dc1d77338b7436abec017e392fc1bdbe3d7"
 [2.2.x] Fixed #30091 -- Doc'd middleware ordering requirements with
 CSRF_USE_SESSIONS.

 Backport of bae66e759faee8513da4b11d3fd16b044b415bdb from master.
 }}}

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

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

Re: [Django] #30091: Incorrect middleware ordering allows invalid HTTP_HOST header to cause CsrfViewMiddleware failure when using CSRF_USE_SESSIONS.

[Django]

#30091: Incorrect middleware ordering allows invalid HTTP_HOST header to cause
CsrfViewMiddleware failure when using CSRF_USE_SESSIONS.
-+-
 Reporter:  Mark Gregson |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  middleware   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"bae66e759faee8513da4b11d3fd16b044b415bdb" bae66e75]:
 {{{
 #!CommitTicketReference repository=""
 revision="bae66e759faee8513da4b11d3fd16b044b415bdb"
 Fixed #30091 -- Doc'd middleware ordering requirements with
 CSRF_USE_SESSIONS.
 }}}

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

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

Re: [Django] #30145: SQLCompiler do not escape names correctly

[Django]

#30145: SQLCompiler do not escape names correctly
-+-
 Reporter:  Artem Skoretskiy |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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:

 `SQLCompiler` isn't a public API. Any usage is at your own risk.

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

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

[Django] #30145: SQLCompiler do not escape names correctly

[Django]

#30145: SQLCompiler do not escape names correctly
-+-
   Reporter:  Artem  |  Owner:  nobody
  Skoretskiy |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I generate custom SQL and I have tried to use `SQLCompiler` to escape
 (quote) table names. But it does not work as expected:

 {{{
 >>> from django.contrib.auth.models import User
 >>> qs = User.objects.all()
 >>> compiler = qs.query.get_compiler(using=qs.db)
 >>> name = 'b"; drop table "world'
 >>> sql = 'alter table x rename column a to
 {};'.format(compiler.quote_name_unless_alias(name))
 >>> print(sql)
 alter table x rename column a to "b"; drop table "world";
 }}}

 I would expect that it would return name that I could use in raw SQL.

 You could try youself:

 {{{
 docker run -ti --rm python:3.7-alpine sh -c "pip install -q
 https://github.com/django/django/archive/master.zip && django-admin.py
 startproject project . && ./manage.py shell"
 }}}

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

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

Re: [Django] #30116: Drop support for Python 3.5

[Django]

#30116: Drop support for Python 3.5
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  master
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7e6b214ed34f5562dbd83cf54924a5b589a29715" 7e6b214]:
 {{{
 #!CommitTicketReference repository=""
 revision="7e6b214ed34f5562dbd83cf54924a5b589a29715"
 Fixed #30116 -- Dropped support for Python 3.5.
 }}}

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

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

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames()

[Django]

#29393: Infinite loop in ExceptionReporter.get_traceback_frames()
-+
 Reporter:  James Howe   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 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):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #29887: Add support for pymemcache

[Django]

#29887: Add support for pymemcache
-+-
 Reporter:  Adrian Turjak|Owner:  Maina
 Type:   |  Nick
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  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 Kosei Kitahara):

 I'm a maintener of [https://github.com/django-pymemcache/django-
 pymemcache]
 Some API are different from python-memcache and pymemcache.
 So I override pymemcache.HashClient and override some method to support
 python-memcached's API

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

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

Re: [Django] #25791: Implement autoreload behaviour for cached template loader

[Django]

#25791: Implement autoreload behaviour for cached template loader
-+-
 Reporter:  Jaap Roes|Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload   | Triage Stage:  Accepted
  templates cached loader|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jaap Roes):

 I want to add that not having some form template caching during
 development may cause performance issues that only happen during
 development. This might cause a developer to try to mitigate the perceived
 slowness by rolling their own form of template caching. A real world
 example of this happening is this wagtail issue:
 https://github.com/wagtail/wagtail/pull/3077

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

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

Re: [Django] #30144: Support passing timedelta for cache timeout

[Django]

#30144: Support passing timedelta for cache timeout
-+-
 Reporter:  Nguyễn Hồng Quân |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  2.1
 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 Nguyễn Hồng Quân):

 Nothing wrong, but passing a `timedelta` data type to that `timeout`
 parameter feels more "native", "Pythonic".

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

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

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

[Django]

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Accepted
  timezone, datetime |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * needs_better_patch:  1 => 0


Comment:

 I needed help about sqlite3 date parse process. I've tried to solve it in
 _sqlite_datetime_parse func.

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

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

Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644.

[Django]

#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
-+-
 Reporter:  Evgeny Arshinov  |Owner:  Himanshu
 Type:   |  Lakhara
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Himanshu Lakhara):

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

Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644.

[Django]

#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
--+
 Reporter:  Evgeny Arshinov   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 > Shall we move it to 3.0 release?

 Yes please.

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

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

Re: [Django] #30144: Support passing timedelta for cache timeout

[Django]

#30144: Support passing timedelta for cache timeout
-+-
 Reporter:  Nguyễn Hồng Quân |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  2.1
 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


Comment:

 What's wrong with just using `timedelta(minutes=12).seconds`?

 I'm going to say `wontfix` unless there's a more pressing use-case.

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

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

Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644.

[Django]

#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
--+
 Reporter:  Evgeny Arshinov   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Himanshu Lakhara):

 Replying to [comment:8 Carlton Gibson]:

 I see and understand the issue better now. Thanks for the clarification.

 I'll make the changes as you have suggested in your [comment:5 previous
 comment].

 Only question remaining is about introducing this change in 3.0 version.
 Shall we move it to 3.0 release?

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

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

Re: [Django] #29943: Document that admin changelist adds `pk` to ordering

[Django]

#29943: Document that admin changelist adds `pk` to ordering
-+-
 Reporter:  Taha Jahangir|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


Comment:

 Patch needs updating to reflect changes in
 f84ad16ba4bcf5fce6fc76593e0606573dec4697 (which was ref #17198)

 Rough outline of the change needed is something like:

 * If no total ordering existing, `pk` is added.
 * If this causes performance issues, add composite index.

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

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

Re: [Django] #30116: Drop support for Python 3.5

[Django]

#30116: Drop support for Python 3.5
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 There's not consensus to change the policy on the mailing list, so we can
 push forward with 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b84ff0a05a2d711410fffd9fbe66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30004: Set default FILE_UPLOAD_PERMISSION to 0o644.

[Django]

#30004: Set default FILE_UPLOAD_PERMISSION to 0o644.
--+
 Reporter:  Evgeny Arshinov   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 That note is referring to that non-leaf directories are created using the
 process `umask`.  (See
 [https://docs.python.org/3.7/library/os.html#os.makedirs `makedirs()`
 docs].) This is similar to `FILE_UPLOAD_PERMISSIONS`, when not using the
 temporary file upload handler.

 The underlying issue here is the **inconsistency** in file permissions,
 depending on the file size, when using **the default settings** that
 Django provides. There is no such inconsistency with directory
 permissions. As such changes should not be needed to
 `FILE_UPLOAD_DIRECTORY_PERMISSIONS`. (Any issues there would need to be
 addressed under a separate ticket.)

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

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

Re: [Django] #30143: Django query abrupt behaviour

[Django]

#30143: Django query abrupt behaviour
-+-
 Reporter:  Shashank Parekh  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Shashank Parekh):

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


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

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

Re: [Django] #30143: Django query abrupt behaviour

[Django]

#30143: Django query abrupt behaviour
-+-
 Reporter:  Shashank Parekh  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Shashank Parekh:

Old description:

> {{{
> class Model:
>  a = models.CharField(max_length=100)
>  b = models.CharField(max_length=100)
>  c = models.CharField(max_length=100)
>

> query1 = Models.objects.filter(Q(a__in=['1']) |
> Q(b__in=['2'])).filter(**{'c__gte': timezone.datetime(2019,1,1),
> 'c__lte': timezone.datetime(2019,2,1)}).order_by('-c')
>
> query2 = Models.objects.filter(Q(a__in=['1']) |
> Q(b__in=['2'])).filter(**{'c__gte': timezone.datetime(2019,1,1),
> 'c__lte': timezone.datetime(2019,2,1)})
> }}}
>
> **query2 is executed perfectly but query1 is timing out.**
>
> I did explain on query1 and ran the query(on `explain()` output) on MySQL
> directly and it worked absolutely fine.
> query1 worked fine in django1.8 but not in django2.1.
>
> Although, If I use `query1.iterator()` it is working.
>
> **Mysql version = 5.6.39**
> **No of rows in table = 5M**

New description:

 {{{
 class Model:
  a = models.CharField(max_length=100)
  b = models.CharField(max_length=100)
  c = models.DateTimeField(max_length=100)


 query1 = Models.objects.filter(Q(a__in=['1']) |
 Q(b__in=['2'])).filter(**{'c__gte': timezone.datetime(2019,1,1), 'c__lte':
 timezone.datetime(2019,2,1)}).order_by('-c')

 query2 = Models.objects.filter(Q(a__in=['1']) |
 Q(b__in=['2'])).filter(**{'c__gte': timezone.datetime(2019,1,1), 'c__lte':
 timezone.datetime(2019,2,1)})
 }}}

 **query2 is executed perfectly but query1 is timing out.**

 I did explain on query1 and ran the query(on `explain()` output) on MySQL
 directly and it worked absolutely fine.
 query1 worked fine in django1.8 but not in django2.1.

 Although, If I use `query1.iterator()` it is working.

 **Mysql version = 5.6.39**
 **No of rows in table = 5M**

--

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

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