Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

2017-10-04 Thread Django
#28373: TIME_ZONE value in DATABASES settings is not used for date lookup
-+-
 Reporter:  Victor Talpaert  |Owner:  messfish
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  settings ORM lookup  | Triage Stage:  Accepted
  mysql timezone |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by messfish):

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


Re: [Django] #28519: Add filter(), exclude(), and other base QuerySet methods to combined QuerySets (union(), etc.)

2017-10-04 Thread Django
#28519: Add filter(), exclude(), and other base QuerySet methods to combined
QuerySets (union(), etc.)
-+-
 Reporter:  Stanislav Karpov |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union,   | Triage Stage:  Accepted
  intersection, difference   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by messfish):

 * owner:  messfish => (none)
 * status:  assigned => new


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


Re: [Django] #28671: DateTimeField: make auto_now_add just a default value

2017-10-04 Thread Django
#28671: DateTimeField: make auto_now_add just a default value
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Simon Charette):

 * resolution:  worksforme => wontfix


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


Re: [Django] #28671: DateTimeField: make auto_now_add just a default value

2017-10-04 Thread Django
#28671: DateTimeField: make auto_now_add just a default value
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 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 Дилян Палаузов):

 * resolution:  wontfix => worksforme


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


Re: [Django] #28403: Improve the example for FORMAT_MODULE_PATH and add missing formats

2017-10-04 Thread Django
#28403: Improve the example for FORMAT_MODULE_PATH and add missing formats
-+-
 Reporter:  karyon   |Owner:  Ashaba
 Type:   |  John
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ashaba John):

 * status:  new => assigned
 * owner:  nobody => Ashaba John


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

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


Re: [Django] #28680: Document that Func.__init__()'s **extra and as_sql()'s **extra_context aren't escaped

2017-10-04 Thread Django
#28680: Document that Func.__init__()'s **extra and as_sql()'s **extra_context
aren't escaped
--+
 Reporter:  Hynek Cernoch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 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 Hynek Cernoch):

 It is sufficient to be committed anything at first glance it was very
 nice, but probably not to close the issue.

 Another place where it should be added is `docs/topics/security.txt` to be
 easier memorable.

 I think that the word "escaping" is vague and it should be used
 
[https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_4
 :_Escaping_All_User-Supplied_Input "as the last resort" (OWASP)] and an
 ORM is considered more secure than escaping. Escaping means usually to
 protect only some special characters. A simple string `"0) OR (TRUE"` can
 be also dangerous if parsed into `WHERE some_function(field_a,
 %(number)s)`. Extra and extra_context can seem as if safe for simple
 values like "ASC"/"DESC" or pseudo numeric values that are not actually
 converted to number by mistake, but they are not.  It is still more risky
 than RawSQL due to frequent underestimation and misunderstanding what is a
 trusted user input. The string can not be passed insecure in RawSQL by
 "params" because all modern database backends substitute it to SQL by
 after parsing SQL syntax. It is better than to escape by apostrophes at
 the beginning and at the end and to protect apostrophes etc. inside.

 The user could still expect an analogy that `template` and `extra` are
 similar to `RawSQL` and `params` and that the warning is also very
 similar, that is:

 "RawSQL()... You should be very careful to escape any parameters that the
 user can control by using `params` in order to protect against *SQL
 injection*..."

 It should be emphasized that this works differently.

 "as these values aren't escaped when they're inserted into the SQL string"
 + "(unlike RawSQL params)"

 What can be a future improvement:  (maybe I will write something)
 * `arg_joiner` can help to not need `extra` params. Maybe a short example
 of `arg_joiner` will be useful, otherwise the user thinks that he
 understands `extra` params better.
 * There is nothing that helps to protect correctly with "extra". The
 escaping depends on the backend, different for MySQL and for other db.

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


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

2017-10-04 Thread Django
#28643: Complete the ORM Function Library
-+-
 Reporter:  Matthew Pava |Owner:  JunyiJ
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matthew Pava):

 I did find this third-party utility that handles specific PostgreSQL
 functions.  I wonder if there are other backends that they could be ported
 to.
 https://github.com/hypertrack/django-pg-utils

 And I also wonder how all of this connects with specific PostgreSQL
 aggregate functions already builtin to Django:
 https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/aggregates/

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

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


[Django] #28682: QuerySet.update() : return the IDs of the matched rows

2017-10-04 Thread Django
#28682: QuerySet.update() : return the IDs of the matched rows
-+-
   Reporter:  Дилян  |  Owner:  nobody
  Палаузов   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  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  |
-+-
 By coincidence all backends that can_return_ids_from_bulk_insert, which
 happens to be only Postgresql, can also return ids from UPDATE:

 UPDATE ... SET ... RETURNING id;

 * update QuerySet.update() to return the PKs of the updated rows
 * update the documentation of QuerySet.update(), stating the specific
 return type for PG
 * possibly rename can_return_ids_from_bulk_insert to can_return_ids or
 can_return_anything(_from_select_insert_update_delete)?

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

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


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

2017-10-04 Thread Django
#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * cc: Дилян Палаузов (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.2e9a1e44863d99066ff8365794a7c7bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28670: Add native LIMIT/OFFSET support on Oracle.

2017-10-04 Thread Django
#28670: Add native LIMIT/OFFSET support on Oracle.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"03da070f5cfda592a174f8c19349638656a521b2" 03da070]:
 {{{
 #!CommitTicketReference repository=""
 revision="03da070f5cfda592a174f8c19349638656a521b2"
 Refs #28670 -- Moved LIMIT/OFFSET SQL to
 DatabaseOperations.limit_offset_sql().

 Thanks Tim Graham for the review.
 }}}

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

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


Re: [Django] #22503: Inconsistent behavior when a QuerySet is sliced

2017-10-04 Thread Django
#22503: Inconsistent behavior when a QuerySet is sliced
-+-
 Reporter:  Luis A. Arce |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet, filter,| Triage Stage:  Accepted
  slice  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * cc: Дилян Палаузов (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/064.0ed4828a614250d368edd5b9a4d26240%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24279: ORing with an empty Q() produces inconsistent results

2017-10-04 Thread Django
#24279: ORing with an empty Q() produces inconsistent results
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q empty in or| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * cc: Дилян Палаузов (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.4b99f17ad5929bceef4f79aa7d235a5e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22503: Inconsistent behavior when a QuerySet is sliced

2017-10-04 Thread Django
#22503: Inconsistent behavior when a QuerySet is sliced
-+-
 Reporter:  Luis A. Arce |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet, filter,| Triage Stage:  Accepted
  slice  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 Is this fixed?  The last comments suggest so, but the status is "new".

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

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


Re: [Django] #24279: ORing with an empty Q() produces inconsistent results

2017-10-04 Thread Django
#24279: ORing with an empty Q() produces inconsistent results
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Q empty in or| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 Is this fixed or not?  The last comment says it is, but the status is "new
 Bug".

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


Re: [Django] #28681: QuerySet.get() implies LIMIT 2

2017-10-04 Thread Django
#28681: QuerySet.get() implies LIMIT 2
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Дилян Палаузов):

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


Re: [Django] #28519: Add filter(), exclude(), and other base QuerySet methods to combined QuerySets (union(), etc.)

2017-10-04 Thread Django
#28519: Add filter(), exclude(), and other base QuerySet methods to combined
QuerySets (union(), etc.)
-+-
 Reporter:  Stanislav Karpov |Owner:  messfish
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union,   | Triage Stage:  Accepted
  intersection, difference   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by messfish):

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


Re: [Django] #28681: QuerySet.get() implies LIMIT 2

2017-10-04 Thread Django
#28681: QuerySet.get() implies LIMIT 2
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (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
-+-
Changes (by Tim Graham):

 * type:  Uncategorized => Cleanup/optimization


Comment:

 Duplicate of #6785.

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


[Django] #28681: QuerySet.get() implies LIMIT 2

2017-10-04 Thread Django
#28681: QuerySet.get() implies LIMIT 2
-+-
   Reporter:  Дилян  |  Owner:  nobody
  Палаузов   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  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  |
-+-
 If the database finds at least two results upon QuerySet.get() it can stop
 working, and Django will raise anyway MultipleObjectsReturned .

 {{{
 diff --git a/django/db/models/query.py b/django/db/models/query.py
 --- a/django/db/models/query.py
 +++ b/django/db/models/query.py
 @@ -370,9 +370,10 @@ class QuerySet(object):
  clone = self.filter(*args, **kwargs)
  if self.query.can_filter() and not self.query.distinct_fields:
  clone = clone.order_by()
 +clone = clone[:2]
  num = len(clone)
  if num == 1:
 -return clone._result_cache[0]
 +return clone[0]
  if not num:
  raise self.model.DoesNotExist(
  "%s matching query does not exist." %
 }}}

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

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


Re: [Django] #28616: DISTINCT ON and update() does the wrong thing

2017-10-04 Thread Django
#28616: DISTINCT ON and update() does the wrong thing
-+-
 Reporter:  Daniel Keller|Owner:  messfish
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by messfish):

 * status:  new => assigned
 * owner:  nobody => messfish


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


Re: [Django] #28667: Documentation for extending UserCreationForm doesn't work with UserAdmin

2017-10-04 Thread Django
#28667: Documentation for extending UserCreationForm doesn't work with UserAdmin
-+-
 Reporter:  Nathanael Gordon |Owner:  messfish
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  add_fieldsets| Triage Stage:  Accepted
  UserAdmin UserCreationForm Custom  |
  Auth User Model|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by messfish):

 * owner:  nobody => messfish
 * status:  new => assigned


Comment:

 I would like to fix this minor problem to let me have a better grasp of
 django.

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


Re: [Django] #28680: Document that Func.__init__()'s **extra and as_sql()'s **extra_context aren't escaped (was: Document that Func's.__init__()'s **extra and as_sql()'s **extra_context aren't escaped

2017-10-04 Thread Django
#28680: Document that Func.__init__()'s **extra and as_sql()'s **extra_context
aren't escaped
--+
 Reporter:  Hynek Cernoch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 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/9202 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.3cdb3dc5198f9759b2ae895a4fc5c86f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28680: Document that Func's.__init__()'s **extra and as_sql()'s **extra_context aren't escaped

2017-10-04 Thread Django
#28680: Document that Func's.__init__()'s **extra and as_sql()'s **extra_context
aren't escaped
--+
 Reporter:  Hynek Cernoch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 Marc Tamlyn says, "An admonition in
 [https://docs.djangoproject.com/en/dev/ref/models/expressions/#func-
 expressions the docs for Func()] should be sufficient I think. At present
 those docs are mostly about using the "simple" template syntax rather than
 handling SQL and params "the long way" and returning `(sql, params)` from
 the `as_sql()` method. I think this might be a dangerous approach to the
 docs and we should be more explicit earlier about separating params from
 chunks of sql. There's a warning in the docs for `RawSQL` but it's not
 really discussed enough in the expressions reference IMO."

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


[Django] #28680: Document that Func's.__init__()'s **extra and as_sql()'s **extra_context aren't escaped

2017-10-04 Thread Django
#28680: Document that Func's.__init__()'s **extra and as_sql()'s **extra_context
aren't escaped
+
   Reporter:  Hynek Cernoch |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  1.11
   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 |
+
 I found an SQL injection possibility due to unclear documentation about
 query expression:

 `class Func(*expressions, **extra)`

 if unsafe user input is passed by keyword parameters `extra` it is
 unprotected, while positional parameters are protected by compile and
 passing through sql execute parameters, never merged to SQL by % format.
 {{{
 class Position(Func):
 function = 'POSITION'
 template = "%(function)s('%(substring)s' in %(expressions)s)"

 def __init__(self, expression, substring):
 super(Position, self).__init__(expression, substring=substring)
 }}}

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


Re: [Django] #28636: Allow customizing the fallback language from the locale middleware

2017-10-04 Thread Django
#28636: Allow customizing the fallback language from the locale middleware
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:  Accepted
  internationalization, request  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Denis Anuschewski):

 OK, here is what I ended up with: could you maybe take a look and tell me
 what you think?
 https://github.com/django/django/compare/master...claudep:28636?expand=1

 With this approach you can set your custom fallback exactly like with your
 changes by setting the middleware's class variable, but with an additional
 fallback for missing translations.

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


Re: [Django] #28676: Using select_for_update with next save() in multiple threads stucks

2017-10-04 Thread Django
#28676: Using select_for_update with next save() in multiple threads stucks
-+-
 Reporter:  M1ha Shvn|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  django psycopg   | Triage Stage:
  PostgreSQL select_for_update   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by M1ha Shvn):

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


Re: [Django] #28676: Using select_for_update with next save() in multiple threads stucks

2017-10-04 Thread Django
#28676: Using select_for_update with next save() in multiple threads stucks
-+-
 Reporter:  M1ha Shvn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  django psycopg   | Triage Stage:
  PostgreSQL select_for_update   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by M1ha Shvn):

 Replying to [comment:2 M1ha Shvn]:
 > Replying to [comment:1 Tim Graham]:
 > > Can you explain why Django is at fault?
 >
 > 1) According to  [https://www.postgresql.org/docs/9.2/static/monitoring-
 stats.html PostgreSQL docs] state "idle in transaction" means that query
 was executed and control returned to backend code, but it hasn't committed
 the transaction yet. But save() is stuck somewhere (it is incorrect). If I
 place print(123) after it - it will not print anything. So PostgreSQL
 ended its work, but save() method stopped, waiting for something and not
 continuing code execution. The expected behavior of django here is to
 leave save() method, than leave "with transaction.atomic" context manager
 and commit transaction, so other transaction can go in. The proof is
 replacing save() method with QuerySet.update(). As you can see on the
 screen, it generates perfectly the same SQL, but works fine without
 stucking.
 > 2) The second strange factor is duplicate select query, generated inside
 save() method. As you can see from above and screen, it's the same query
 without "FOR UPDATE". But there is no need in this query - conversation
 data has been already selected by "SELECT ... FOR UPDATE". According to
 [https://docs.djangoproject.com/en/1.10/ref/models/instances/#what-
 happens-when-you-save the docs], save() should do only one query - INSERT
 or UPDATE (UPDATE in this situation) without any SELECT queries.
 > P. s. The only reason for save() of doing second SELECT from the docs is
 getting pk value. But it is not INSERT query, pk is already defined.
 Moreover force_update=True doesn't change anything.
 >
 > Replying to [comment:1 Tim Graham]:
 > > propose a change to fix it
 > I'm not quite good in django inner code, I've tried debugging where,
 inside save() method, the problem is, but haven't succeeded

 1) Futher investigation shows that [https://github.com/Suor/django-
 cacheops django-cacheops] invalidated_update() also doesn't work. Seems
 it's bug of this extension.

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