Re: [Django] #28198: Model attributes shouldn't override deferred fields

[Django]

#28198: Model attributes shouldn't override deferred fields
-+-
 Reporter:  Ryan Hiebert |Owner:
 |  Denis.Tarykin
 Type:  Bug  |   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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 I left some comments for improvement on the pull request. Please uncheck
 "Patch needs improvement" after updating.

-- 
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/069.f7f671038bda9a0308dc50466ac6a0fb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17448: Error reading PointField in objects.raw(sql) query

[Django]

#17448: Error reading PointField in objects.raw(sql) query
-+
 Reporter:  oluckyman|Owner:  David Eklund
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  raw sql gis  | 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 ):

 In [changeset:"69922d303dbe8e83952f769caff205abbe100bba" 69922d3]:
 {{{
 #!CommitTicketReference repository=""
 revision="69922d303dbe8e83952f769caff205abbe100bba"
 Refs #17448 -- Fixed GeoModelTest.test_raw_sql_query.

 The test was a false positive.
 }}}

-- 
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.161aa0f3c815ba06a233ef1393253a30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28518: improve performance of loading geometries from DB

[Django]

#28518: improve performance of loading geometries from DB
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"8869142a4d5b069c61781c0e4c5fdc971b017949" 8869142a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8869142a4d5b069c61781c0e4c5fdc971b017949"
 Fixed #28632 -- Updated docs about using raw SQL with GIS and doc'd
 changes from refs #28518 in release notes.
 }}}

-- 
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.7d1b5f6629bb287674f32e9c98fa5e8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28632: Manager.raw() crashes if the model has GIS fields

[Django]

#28632: Manager.raw() crashes if the model has GIS fields
-+-
 Reporter:  gcbirzan |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  2.0
 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 Tim Graham ):

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


Comment:

 In [changeset:"8869142a4d5b069c61781c0e4c5fdc971b017949" 8869142a]:
 {{{
 #!CommitTicketReference repository=""
 revision="8869142a4d5b069c61781c0e4c5fdc971b017949"
 Fixed #28632 -- Updated docs about using raw SQL with GIS and doc'd
 changes from refs #28518 in release notes.
 }}}

-- 
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.068dfde332a2f455e7b0df7ae06d01a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28404: Django admin empty_value/empty_value_display doesn't check for empty strings

[Django]

#28404: Django admin empty_value/empty_value_display doesn't check for empty
strings
-+-
 Reporter:  Mark Koh |Owner:  Nazarov
 |  Georgiy
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  empty value display  | Triage Stage:  Accepted
  admin charfield|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Nazarov Georgiy):

 * owner:  nobody => Nazarov Georgiy
 * 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/068.043e70ceaf8a9afe04853e6c23767059%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28766: Add route information to ResolverMatch

[Django]

#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Benjamin
 |  Wohlwend
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  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 Tomer Chachamu):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the patch. If it's ready to review you can deassign the Trac
 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.a17cc43106ef9e51d97dd559cd283fb2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

[Django]

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  Matthew Schinckel|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  check contsraint | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ian Foote):

 * needs_better_patch:  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 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.0c63cf0872ac449c1b58ef4aa4edbe43%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28632: Manager.raw() crashes if the model has GIS fields

[Django]

#28632: Manager.raw() crashes if the model has GIS fields
-+-
 Reporter:  gcbirzan |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  2.0
 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 Tim Graham ):

 In [changeset:"a44fb4aa02ed6d87f22d96a48907dbe833e1d392" a44fb4aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="a44fb4aa02ed6d87f22d96a48907dbe833e1d392"
 [2.0.x] Fixed #28632 -- Updated docs about using raw SQL with GIS and
 doc'd changes from refs #28518 in release notes.

 Backport of 8869142a4d5b069c61781c0e4c5fdc971b017949 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.a3eb2ba0ae0b0955865e1ffbb0ad8661%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17448: Error reading PointField in objects.raw(sql) query

[Django]

#17448: Error reading PointField in objects.raw(sql) query
-+
 Reporter:  oluckyman|Owner:  David Eklund
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  raw sql gis  | 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 ):

 In [changeset:"9e12e02afdadcea438f6f706e4fbae5dc659ac3a" 9e12e02a]:
 {{{
 #!CommitTicketReference repository=""
 revision="9e12e02afdadcea438f6f706e4fbae5dc659ac3a"
 [2.0.x] Refs #17448 -- Fixed GeoModelTest.test_raw_sql_query.

 The test was a false positive.

 Backport of 69922d303dbe8e83952f769caff205abbe100bba 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/067.b609ae7cea795a65134fd069ba0ebdb7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28518: improve performance of loading geometries from DB

[Django]

#28518: improve performance of loading geometries from DB
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"a44fb4aa02ed6d87f22d96a48907dbe833e1d392" a44fb4aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="a44fb4aa02ed6d87f22d96a48907dbe833e1d392"
 [2.0.x] Fixed #28632 -- Updated docs about using raw SQL with GIS and
 doc'd changes from refs #28518 in release notes.

 Backport of 8869142a4d5b069c61781c0e4c5fdc971b017949 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/068.705e6f3691c09eb0e66d07e5111d512d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28764: Store staticfiles.json with code

[Django]

#28764: Store staticfiles.json with code
-+-
 Reporter:  Kevin Christopher|Owner:  nobody
  Henry  |
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.staticfiles  |  Version:  1.11
 Severity:  Normal   |   Resolution:  duplicate
 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:   => duplicate


-- 
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.751dec83ff4e9969307df319ee9cc7d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28766: Add route information to ResolverMatch

[Django]

#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Benjamin
 |  Wohlwend
 Type:  New feature  |   Status:  assigned
Component:  Core (URLs)  |  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
-+-

Comment (by Tim Graham):

 For URL patterns that use `re_path()` is the route already available from
 `ResolverMatch`? If not, I'm unsure why this attribute would only be set
 for `path()`.

 (By the way, there's no need to deassign the ticket to get it in the
 review queue.)

-- 
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.fb77bdf1267d2dfd712998966e507b98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28767: Incorrect value when annotating empty list as Value() on ArrayField.

[Django]

#28767: Incorrect value when annotating empty list as Value() on ArrayField.
---+
 Reporter:  Matthew Schinckel  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.postgres   |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords:  annotate   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 #28762 may be related if not a duplicate.

-- 
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.7e7fd243279d2982001e54659b58a482%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28762: Can't aggregate annotations with array parameters

[Django]

#28762: Can't aggregate annotations with array parameters
-+-
 Reporter:  Daniel Keller|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 #28767 may be related if not a duplicate.

-- 
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.da9398760f5b00c51c4445998645de8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28770: Warn that quoting a placeholder in a raw SQL string can lead to SQL injection

[Django]

#28770: Warn that quoting a placeholder in a raw SQL string can lead to SQL
injection
+
   Reporter:  Hynek Cernoch |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 This is a follow up to #28680 which addresses the the security of `Func()`
 query expression if used with unsafe `extra` or `extra_context`.

 I have found a similar issue in:
 {{{
 models.query.QuerySet.extra(... params=...)
 models.expressions.RawSQL(... params=...)
 models.Manager.raw(... params=...)
 cursor.execute(... params=...)
 }}}
 if the SQL is constructed carelessly with apostrophes around the parameter
 placeholder " '%s' " and the parameter was obtained from a user input by:
 a) by JSON without a type control, or
 b) by guessing the type
 c) with an obsoleted unused parameter in a more complicated query that has
 not been ever tested.

 Example:
 {{{
 from django.contrib.auth.models import User

 class Data(models.Model):
 user = models.ForeignKey(User, models.DO_NOTHING)
 option = models.CharField(max_length=20)
 val = models.IntegerField()
 secret = models.CharField(max_length=100)
 }}}
 --- view common part ---
 {{{
 # common part - get Data for the current authenticated user
 qs = Data.objects.filter(user=request.user)

 # attack to get all Data
 }}}
 A) vulnerable code - added filter by JSON data without a type control
 {{{
 user_data = """{"val": 1}"""  # expected example
 user_data = """{"val": ") OR TRUE OR (val="}"""'  # attack example
 val= json.loads(json_data)['val']
 qs = qs.extra(where=["val='%s'"], params=[val]])
 }}}
 B) vulnerable code - guess a type  (very similar)
 {{{
 user_data = "1" # expected example
 user_data = ") OR TRUE OR (val="# attack example
 val = int(user_data) if user_data.isdigit() else user_data
 qs = qs.extra(where=["val='%s'"], params=[val])
 }}}
 C) vulnerable due to an unused obsoleted request variable 'user_data'
 {{{
 user_data = ''   # usual value of an unused
 field
 user_data = ')); DROP TABLE ...; --' # attack example
 qs = qs.extra(where=["val > 0 OR val < 0 AND option='%s'"],
 params=[user_data])
 # if negative values `val` are not expected seriously then the query
 could be untested enough
 }}}
 Backends:
 - mysql - all A, B, C) vulnerable
 - postgresql - vulnerable C)
 - sqlite3 - seems safe

 A complete code with a test is in attachment.

 If I compare these vulnerabilities with #28680 Func(), it is less probable
 that the invalid SQL will work and some circumstances like A), B) or C)
 are necessary. On the other hand these functions are probably much more
 used (by my experience at StackOverflow)

 Generally, escaping of parameters by a database driver is a safe technique
 if the SQL is carefully constructed. That is still OK for ORM generated
 queries, but generally not for manually constructed parts of SQL like in
 the functions above.

 A separation of SQL and data by parameterized queries is also a safe
 technique if it is done consistently from the beginning up to a
 parameterized call to database server. But it is not a case of most Django
 db drivers.

 I expect that also this issue will be solved by documentation first. A
 security scanner for SQL can be used later. It can identify suspicious SQL
 at run-time in debug mode and write warnings.

 The
 
[https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.extra
 current docs for extra()]:

 > Warning:
 > You should be very careful whenever you use extra(). Every time you use
 it, you should escape any parameters that the user can control by using
 params in order to protect against SQL injection attacks . Please read
 more about SQL injection protection.

 Similar texts are for `RawSQL()` and `raw()`.

 something similar to [http://initd.org/psycopg/docs/usage.html#the-
 problem-with-the-query-parameters psycopg's docs] is useful:

  ...   ('%s');" # NEVER DO THIS
  ...   (%s);" # Note: no quotes

 This can be reported as an issue to driver development. A check there is
 more effective.

-- 
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 

Re: [Django] #28752: django.setup() should not be runnable multiple times

[Django]

#28752: django.setup() should not be runnable multiple times
+--
 Reporter:  pascal chambon  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Core (Other)|  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Old description:

> I've been bitten numerous times by the impredictable behaviour of django
> when django.setup() was called numerous times.
>
> In the old days I had exceptions, now it's mainly subtle breakages of
> logging configuration.
>
> I couldn't find, in the issue tracker or the dev mailing list statements
> about this subject, others than request from other users encountering the
> problem.
>
> For example #26152 concerned script+importable modules.
>
> The latest case in date for me is pytest-django having troubles with
> these multiple setup() calls : https://github.com/pytest-dev/pytest-
> django/issues/531 , due to multiple fixtures attempting this auto-setup.
>
> Would it be OK to make django.setup() idempotent, or even expose an
> "is_ready" flag for easier introspection ?
>
> -- here are some updates, comments get rejected as spam --
>
> Calling django.setup() multiple times is useless, BUT it can happen in
> lots of cases, that's why imho this case should be handled by the
> framework to avoid nasty side effects.
>
> These "duplicate calls" often involve the collision between manage.py
> commands, tests, custom scripts, and external launchers like pytest-
> django. Plus maybe some corner cases when unittest-style TestCases and
> pytest-style test functions are mixed in the same project.
>
> Users have to do a real gym to call setup() "at some moment" in all these
> use cases, yet try to prevent multiple calls of this initialization step
> (like the 'if__name__ == "main"' protection). So far my only way out was
> often to check for (not really undocumented) states of the framework
> before calling setup().

New description:

 I've been bitten numerous times by the impredictable behaviour of django
 when django.setup() was called numerous times.

 In the old days I had exceptions, now it's mainly subtle breakages of
 logging configuration.

 I couldn't find, in the issue tracker or the dev mailing list statements
 about this subject, others than request from other users encountering the
 problem.

 For example #26152 concerned script+importable modules.

 The latest case in date for me is pytest-django having troubles with these
 multiple setup() calls : https://github.com/pytest-dev/pytest-
 django/issues/531 , due to multiple fixtures attempting this auto-setup.

 Would it be OK to make django.setup() idempotent, or even expose an
 "is_ready" flag for easier introspection ?

 -- here are some updates, comments get rejected as spam --

 Calling django.setup() multiple times is useless, BUT it can happen in
 lots of cases, that's why imho this case should be handled by the
 framework to avoid nasty side effects.

 These "duplicate calls" often involve the collision between manage.py
 commands, tests, custom scripts, and external launchers like pytest-
 django. Plus maybe some corner cases when unittest-style TestCases and
 pytest-style test functions are mixed in the same project.

 Users have to do a real gym to call setup() "at some moment" in all these
 use cases, yet try to prevent multiple calls of this initialization step
 (like the `if__name__ == "main"'` protection). So far my only way out was
 often to check for (not really undocumented) states of the framework
 before calling setup().

--

Comment (by Tim Graham):

 I don't know. Does that change risk breaking working code where multiple
 calls to `django.setup()` has an intended effect?

-- 
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.69f40a5106663af7af7fd4c49c878d53%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28769: Utilize 'x or y' in place of 'x if x else y'

[Django]

#28769: Utilize 'x or y' in place of 'x if x else y'
--+
   Reporter:  Дилян Палаузов  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  1.11
   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   |
--+
 {{{
 diff --git a/django/contrib/admin/bin/compress.py
 b/django/contrib/admin/bin/compress.py
 --- a/django/contrib/admin/bin/compress.py
 +++ b/django/contrib/admin/bin/compress.py
 @@ -28,7 +28,7 @@ Compiler library and Java version 6 or later."""
  parser.add_argument("-q", "--quiet", action="store_false",
 dest="verbose")
  options = parser.parse_args()

 -compiler = Path(closure_compiler if closure_compiler else
 options.compiler).expanduser()
 +compiler = Path(closure_compiler or options.compiler).expanduser()
  if not compiler.exists():
  sys.exit(
  "Google Closure compiler jar file %s not found. Please use
 the -c "
 diff --git a/django/contrib/gis/gdal/raster/base.py
 b/django/contrib/gis/gdal/raster/base.py
 --- a/django/contrib/gis/gdal/raster/base.py
 +++ b/django/contrib/gis/gdal/raster/base.py
 @@ -56,7 +56,7 @@ class GDALRasterBase(GDALBase):
  counter += 1
  item = data[counter]
  # The default domain values are returned if domain is None.
 -result[domain if domain else 'DEFAULT'] = domain_meta
 +result[domain or 'DEFAULT'] = domain_meta
  return result

  @metadata.setter
 diff --git a/django/core/management/commands/makemessages.py
 b/django/core/management/commands/makemessages.py
 --- a/django/core/management/commands/makemessages.py
 +++ b/django/core/management/commands/makemessages.py
 @@ -323,9 +323,9 @@ class Command(BaseCommand):
  raise CommandError("currently makemessages only supports
 domains "
 "'django' and 'djangojs'")
  if self.domain == 'djangojs':
 -exts = extensions if extensions else ['js']
 +exts = extensions or  ['js']
  else:
 -exts = extensions if extensions else ['html', 'txt', 'py']
 +exts = extensions or ['html', 'txt', 'py']
  self.extensions = handle_extensions(exts)

  if (locale is None and not exclude and not process_all) or
 self.domain is None:
 diff --git a/django/db/backends/base/introspection.py
 b/django/db/backends/base/introspection.py
 --- a/django/db/backends/base/introspection.py
 +++ b/django/db/backends/base/introspection.py
 @@ -130,7 +130,7 @@ class BaseDatabaseIntrospection:
  # we don't need to reset the sequence.
  if f.remote_field.through is None:
  sequence = self.get_sequences(cursor,
 f.m2m_db_table())
 -sequence_list.extend(sequence if sequence else
 [{'table': f.m2m_db_table(), 'column': None}])
 +sequence_list.extend(sequence or [{'table':
 f.m2m_db_table(), 'column': None}])
  return sequence_list

  def get_sequences(self, cursor, table_name, table_fields=()):
 diff --git a/django/db/models/sql/query.py b/django/db/models/sql/query.py
 --- a/django/db/models/sql/query.py
 +++ b/django/db/models/sql/query.py
 @@ -606,7 +606,7 @@ class Query:

  # Ordering uses the 'rhs' ordering, unless it has none, in which
 case
  # the current ordering is used.
 -self.order_by = rhs.order_by if rhs.order_by else self.order_by
 +self.order_by = rhs.order_by or self.order_by
  self.extra_order_by = rhs.extra_order_by or self.extra_order_by

  def deferred_to_data(self, target, callback):
 diff --git a/django/forms/widgets.py b/django/forms/widgets.py
 --- a/django/forms/widgets.py
 +++ b/django/forms/widgets.py
 @@ -474,7 +474,7 @@ class DateTimeBaseInput(TextInput):

  def __init__(self, attrs=None, format=None):
  super().__init__(attrs)
 -self.format = format if format else None
 +self.format = format or None

  def format_value(self, value):
  return formats.localize_input(value, self.format or
 formats.get_format(self.format_key)[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 

Re: [Django] #28769: Utilize 'x or y' in place of 'x if x else y'

[Django]

#28769: Utilize 'x or y' in place of 'x if x else y'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)
 * type:  Uncategorized => Cleanup/optimization


Comment:

 I'm not sure if that's an improvement.
 [https://www.python.org/dev/peps/pep-0308/ Conditional expressions] were
 added to Python to address "the prevalence of error-prone attempts to
 achieve the same effect using 'and' and 'or'". I think they're more
 explicit than using "or".

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

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

Re: [Django] #28769: Utilize 'x or y' in place of 'x if x else y'

[Django]

#28769: Utilize 'x or y' in place of 'x if x else y'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Дилян Палаузов):

 This is already inconsistent in the code:
 {{{
 django/db/migrations/operations/models.py:48:self.options =
 options or {}
 django/db/migrations/operations/models.py:49:self.bases = bases or
 (models.Model,)
 django/db/migrations/operations/special.py:17:
 self.database_operations = database_operations or []
 django/db/migrations/operations/special.py:18:
 self.state_operations = state_operations or []
 django/db/migrations/operations/special.py:75:
 self.state_operations = state_operations or []
 django/db/migrations/operations/special.py:76:self.hints = hints
 or {}
 django/db/migrations/operations/special.py:153:self.hints = hints
 or {}
 django/db/migrations/state.py:88:self.models = models or {}
 django/db/migrations/state.py:90:self.real_apps = real_apps or []
 django/db/migrations/state.py:363:self.options = options or {}
 django/db/migrations/state.py:365:self.bases = bases or
 (models.Model, )
 django/db/migrations/state.py:366:self.managers = managers or []
 }}}

 Adding ternary expression to avoid using incorrectly or/and is fine, but
 it was not added to start using "x if x else y" instead of "x or y".

 There are more places which can be shortened this way:
 {{{
 diff --git a/django/contrib/sessions/backends/file.py
 b/django/contrib/sessions/backends/file.py
 --- a/django/contrib/sessions/backends/file.py
 +++ b/django/contrib/sessions/backends/file.py
 @@ -73,10 +73,7 @@ class SessionStore(SessionBase):
  """
  Return the expiry time of the file storing the session's content.
  """
 -expiry = session_data.get('_session_expiry')
 -if not expiry:
 -expiry = self._last_modification() +
 datetime.timedelta(seconds=settings.SESSION_COOKIE_AGE)
 -return expiry
 +return session_data.get('_session_expiry') or
 self._last_modification() +
 datetime.timedelta(seconds=settings.SESSION_COOKIE_AGE)

  def load(self):
  session_data = {}
 diff --git a/django/core/handlers/wsgi.py b/django/core/handlers/wsgi.py
 --- a/django/core/handlers/wsgi.py
 +++ b/django/core/handlers/wsgi.py
 @@ -66,13 +66,11 @@ class LimitedStream:
  class WSGIRequest(HttpRequest):
  def __init__(self, environ):
  script_name = get_script_name(environ)
 -path_info = get_path_info(environ)
 -if not path_info:
 +path_info = get_path_info(environ) or '/'
  # Sometimes PATH_INFO exists, but is empty (e.g. accessing
  # the SCRIPT_NAME URL without a trailing slash). We really
 need to
  # operate as if they'd requested '/'. Not amazingly nice to
 force
  # the path like this, but should be harmless.
 -path_info = '/'
  self.environ = environ
  self.path_info = path_info
  # be careful to only replace the first slash in the path because
 of
 diff --git a/django/core/management/commands/makemessages.py
 b/django/core/management/commands/makemessages.py
 --- a/django/core/management/commands/makemessages.py
 +++ b/django/core/management/commands/makemessages.py
 @@ -501,9 +501,7 @@ class Command(BaseCommand):
  locale_dir = path
  break
  if not locale_dir:
 -locale_dir = self.default_locale_path
 -if not locale_dir:
 -locale_dir = NO_LOCALE_DIR
 +locale_dir = self.default_locale_path or
 NO_LOCALE_DIR
 all_files.append(self.translatable_file_class(dirpath, filename,
 locale_dir))
  return sorted(all_files)

 diff --git a/django/db/backends/sqlite3/creation.py
 b/django/db/backends/sqlite3/creation.py
 --- a/django/db/backends/sqlite3/creation.py
 +++ b/django/db/backends/sqlite3/creation.py
 @@ -12,9 +12,7 @@ class DatabaseCreation(BaseDatabaseCreation):
  return database_name == ':memory:' or 'mode=memory' in
 database_name

  def _get_test_db_name(self):
 -test_database_name =
 

Re: [Django] #28770: Warn that quoting a placeholder in a raw SQL string can lead to SQL injection

[Django]

#28770: Warn that quoting a placeholder in a raw SQL string can lead to SQL
injection
--+
 Reporter:  Hynek Cernoch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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
--+
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9327 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/066.c42782608fac13fac571ac130cd44e1e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.