Re: [Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   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 Keryn Knight):

 * cc: Keryn Knight (added)


Comment:

 Possible duplicate of #28826?

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

Re: [Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Sergey Fedoseev:

Old description:

> I noticed this when trying to test Django-MySQL against 2.0 in
> https://github.com/adamchainz/django-mysql/pull/403 . Basically there's a
> function called If() that takes a Q object, and it's tested in a variety
> of scenarios. Only one of those scenarios was crashing with Django 2.0b1
> and rc1.
>
> I found a minimal test to reproduce it in the django test suite:
>
> {{{
> diff --git a/tests/expressions/tests.py b/tests/expressions/tests.py
> index ca331aeb03..d31935ddb4 100644
> --- a/tests/expressions/tests.py
> +++ b/tests/expressions/tests.py
> @@ -73,6 +73,12 @@ class BasicExpressionsTests(TestCase):
>  ],
>  )
>
> +def test_filtering_on_annoate_that_uses_q(self):
> +qs = Company.objects.annotate(
> +name_check_len=Length(Q(name__gt='T'))
> +).filter(name_check_len__gt=1)
> +list(qs)
> +
>  def test_filter_inter_attribute(self):
>  # We can filter on attribute relationships on same model obj,
> e.g.
>  # find companies where the number of employees is greater
> }}}
>
> It fails with this stacktrace:
>
> {{{
> ERROR: test_filtering_on_annoate_that_uses_q
> (expressions.tests.BasicExpressionsTests)
> --
> Traceback (most recent call last):
>   File
> "/Users/chainz/Documents/Projects/django/tests/expressions/tests.py",
> line 80, in test_filtering_on_annoate_that_uses_q
> list(qs)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
> 272, in __iter__
> self._fetch_all()
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
> 1179, in _fetch_all
> self._result_cache = list(self._iterable_class(self))
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
> 54, in __iter__
> results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
> chunk_size=self.chunk_size)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
> line 1050, in execute_sql
> sql, params = self.as_sql()
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
> line 458, in as_sql
> where, w_params = self.compile(self.where) if self.where is not None
> else ("", [])
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
> line 390, in compile
> sql, params = node.as_sql(self, self.connection)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/sql/where.py",
> line 79, in as_sql
> sql, params = compiler.compile(child)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
> line 390, in compile
> sql, params = node.as_sql(self, self.connection)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
> line 160, in as_sql
> lhs_sql, params = self.process_lhs(compiler, connection)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
> line 151, in process_lhs
> lhs_sql, params = super().process_lhs(compiler, connection, lhs)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
> line 77, in process_lhs
> lhs = lhs.resolve_expression(compiler.query)
>   File
> "/Users/chainz/Documents/Projects/django/django/db/models/expressions.py",
> line 597, in resolve_expression
> c.source_expressions[pos] = arg.resolve_expression(query,
> allow_joins, reuse, summarize, for_save)
> AttributeError: 'WhereNode' object has no attribute 'resolve_expression'
> }}}
>
> I then used git bisect with this test and found it bisected to:
>
> {{{
> commit bde86ce9ae17ee52aa5be9b74b64422f5219530d
> Author: Sergey Fedoseev 
> Date:   Sat Apr 1 18:47:49 2017 +0500
>
> Fixed #25605 -- Made GIS DB functions accept geometric expressions,
> not only values, in all positions.
> }}}
>
> This change was the culprit, if you revert only this conditional, the
> test passes:
>
> {{{
> diff --git 

Re: [Django] #28864: Allow overriding the default dropdown list for the time widget in Django admin

[Django]

#28864: Allow overriding the default dropdown list for the time widget in Django
admin
---+--
 Reporter:  jeffrey k eliasen  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  master
 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 jeffrey k eliasen):

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


Comment:

 Ah yes, so it is. Thanks for pointing that out @Tim.

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

Re: [Django] #28864: Allow overriding the default dropdown list for the time widget in Django admin

[Django]

#28864: Allow overriding the default dropdown list for the time widget in Django
admin
---+--
 Reporter:  jeffrey k eliasen  |Owner:  nobody
 Type:  New feature|   Status:  new
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:  0
---+--

Comment (by Tim Graham):

 Duplicate of #25006?

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

[Django] #28864: Allow overriding the default dropdown list for the time widget in Django admin

[Django]

#28864: Allow overriding the default dropdown list for the time widget in Django
admin
-+
   Reporter:  jeffrey k eliasen  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Right now all time widgets in the admin offer a dropdown list of times to
 enter, but the list is only 5 times: "now", "6 am", "noon", "6 pm", and
 "midnight". For most use cases this list is not practical.

 I propose altering the javascript so that the user can either override a
 javascript function that builds the list or (better) alter the widget so
 that details about the start time, stop time, and minutes increment are
 provided as parameters on the TimeField or DateTimeField.

 I will be creating a PR for this change in the next week or so.

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

Re: [Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * cc: Sergey Fedoseev (added)
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.ab079962c57971f328092b97c7a77d98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14642: save_as=True and generic inline in admin gives IndexError

[Django]

#14642: save_as=True and generic inline in admin gives IndexError
-+-
 Reporter:  simon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.4
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  save_as generic  | Triage Stage:  Accepted
  inline |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tomer Chachamu):

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

Re: [Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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
-+-
Changes (by Adam (Chainz) Johnson):

 * severity:  Normal => Release blocker


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

Re: [Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (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/068.d6419a341c7e029734ff9bac7325c65c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28863: Regression in 2.0: an annotated then filtered db function using a Q object crashes

[Django]

#28863: Regression in 2.0: an annotated then filtered db function using a Q 
object
crashes
-+-
   Reporter:  Adam   |  Owner:  nobody
  (Chainz) Johnson   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  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 noticed this when trying to test Django-MySQL against 2.0 in
 https://github.com/adamchainz/django-mysql/pull/403 . Basically there's a
 function called If() that takes a Q object, and it's tested in a variety
 of scenarios. Only one of those scenarios was crashing with Django 2.0b1
 and rc1.

 I found a minimal test to reproduce it in the django test suite:

 {{{
 diff --git a/tests/expressions/tests.py b/tests/expressions/tests.py
 index ca331aeb03..d31935ddb4 100644
 --- a/tests/expressions/tests.py
 +++ b/tests/expressions/tests.py
 @@ -73,6 +73,12 @@ class BasicExpressionsTests(TestCase):
  ],
  )

 +def test_filtering_on_annoate_that_uses_q(self):
 +qs = Company.objects.annotate(
 +name_check_len=Length(Q(name__gt='T'))
 +).filter(name_check_len__gt=1)
 +list(qs)
 +
  def test_filter_inter_attribute(self):
  # We can filter on attribute relationships on same model obj,
 e.g.
  # find companies where the number of employees is greater
 }}}

 It fails with this stacktrace:

 {{{
 ERROR: test_filtering_on_annoate_that_uses_q
 (expressions.tests.BasicExpressionsTests)
 --
 Traceback (most recent call last):
   File
 "/Users/chainz/Documents/Projects/django/tests/expressions/tests.py", line
 80, in test_filtering_on_annoate_that_uses_q
 list(qs)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
 272, in __iter__
 self._fetch_all()
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
 1179, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/query.py", line
 54, in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
 line 1050, in execute_sql
 sql, params = self.as_sql()
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
 line 458, in as_sql
 where, w_params = self.compile(self.where) if self.where is not None
 else ("", [])
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
 line 390, in compile
 sql, params = node.as_sql(self, self.connection)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/sql/where.py",
 line 79, in as_sql
 sql, params = compiler.compile(child)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/sql/compiler.py",
 line 390, in compile
 sql, params = node.as_sql(self, self.connection)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
 line 160, in as_sql
 lhs_sql, params = self.process_lhs(compiler, connection)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
 line 151, in process_lhs
 lhs_sql, params = super().process_lhs(compiler, connection, lhs)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/lookups.py",
 line 77, in process_lhs
 lhs = lhs.resolve_expression(compiler.query)
   File
 "/Users/chainz/Documents/Projects/django/django/db/models/expressions.py",
 line 597, in resolve_expression
 c.source_expressions[pos] = arg.resolve_expression(query, allow_joins,
 reuse, summarize, for_save)
 AttributeError: 'WhereNode' object has no attribute 'resolve_expression'
 }}}

 I then used git bisect with this test and found it bisected to:

 {{{
 commit bde86ce9ae17ee52aa5be9b74b64422f5219530d
 Author: Sergey Fedoseev 
 Date:   Sat Apr 1 18:47:49 2017 +0500

 Fixed #25605 -- Made GIS DB functions accept geometric expressions,
 not only values, in all positions.
 }}}

 This change was the culprit, if you revert only this conditional, the test
 passes:

 {{{
 diff --git a/django/db/models/lookups.py b/django/db/models/lookups.py
 index d96c4468f5..c37fcabba4 100644
 --- a/django/db/models/lookups.py
 +++ b/django/db/models/lookups.py
 @@ -76,6 +76,8 @@ class Lookup:

  def process_lhs(self, compiler, 

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I didn't know that `len()` is an O(1) operation for many types.

 So it looks like for that case, the fastest option would be `True if
 self.lookup_choices else False`.
 {{{
 >>> timeit.timeit('True if [1] else False')
 0.06975528400289477
 >>> timeit.timeit('bool([1])')
 0.18175133999829995
 >>> timeit.timeit('len([1]) > 0')
 0.1232264987334
 }}}
 Is that optimizing at the expense of readability?

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

Re: [Django] #28799: ModelFormSet is incorrectly considered as not valid if initial form is not changed and validate_min=True

[Django]

#28799: ModelFormSet is incorrectly considered as not valid if initial form is 
not
changed and validate_min=True
-+--
 Reporter:  Sergey Fedoseev  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  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 Tim Graham):

 There's a typo in your test: `self.assertTrue(len(formset.save()), 2)`.
 This fails with `assertEqual` as only 1 object is created (from the second
 form). The first, unchanged form is ignored.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.00b93d0401ab63b98568caa2f6ae5b10%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28859: Django hides exception from database with Oracle backend.

[Django]

#28859: Django hides exception from database with Oracle backend.
-+-
 Reporter:  Jani Tiainen |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * owner:  nobody => felixxm
 * version:  1.11 => 2.0
 * stage:  Unreviewed => Accepted


Comment:

 I attached minimal test in the Django test suite "28859.diff​". I'm not
 entirely sure if it's a Django issue or a driver issue. Accepted for
 further investigation.

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

Re: [Django] #28859: Django hides exception from database with Oracle backend.

[Django]

#28859: Django hides exception from database with Oracle backend.
-+-
 Reporter:  Jani Tiainen |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "28859.diff" added.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.37e594bdcb341fe7da95681443a06ca9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin):

 The performance hit is specific to extra `bool` calls.

 `if ` is faster than `if len()`.

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

Re: [Django] #28857: Cast function may generate invalid SQL on PostgreSQL for complex expressions

[Django]

#28857: Cast function may generate invalid SQL on PostgreSQL for complex
expressions
-+-
 Reporter:  Jurica Železnjak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,orm | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.037b922f8724ab05b12fd73052f69a14%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aymeric Augustin):

 Some changes in the patch are indeed improvements, but not all of them.

 Regarding the comment above, I find that `return len(self.lookup_choices)
 > 0` is much more explicit than `return bool(self.lookup_choices)` as well
 as much faster:

 {{{
 >>> import timeit
 >>> timeit.timeit('len([]) > 0')
 0.0808453639911022
 >>> timeit.timeit('bool([])')
 0.1313885069976095
 }}}

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

Re: [Django] #28120: CharField: if max_length=True (or False): makemigrations generates a migration and migrate fails

[Django]

#28120: CharField: if max_length=True (or False): makemigrations generates a
migration and migrate fails
-+-
 Reporter:  Carles Pina Estany   |Owner:  Carles
 |  Pina Estany
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 While uncommon that would prevent user defined `int` subclasses to work
 appropriately.

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

Re: [Django] #28862: Removing a field from index_together and from the model generates a migration that crashes (was: Error in auto-generated migration)

[Django]

#28862: Removing a field from index_together and from the model generates a
migration that crashes
-+-
 Reporter:  elros|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models migrations| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you reproduce that issue with Django 2.0 or Django 1.11? It sounds
 familiar and may have been fixed in a newer version of Django (in general,
 we would always like bug reports to be confirmed against the latest
 version of Django or even Django master, if possible).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.ea13183c59432f6c2806dc19c054f1ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 Even more places:
 {{{
 diff --git a/django/contrib/admin/filters.py
 b/django/contrib/admin/filters.py
 --- a/django/contrib/admin/filters.py
 +++ b/django/contrib/admin/filters.py
 @@ -77,7 +77,7 @@ class SimpleListFilter(ListFilter):
  self.lookup_choices = list(lookup_choices)

  def has_output(self):
 -return len(self.lookup_choices) > 0
 +return bool(self.lookup_choices)

  def value(self):
  """
 diff --git a/django/db/backends/oracle/creation.py
 b/django/db/backends/oracle/creation.py
 --- a/django/db/backends/oracle/creation.py
 +++ b/django/db/backends/oracle/creation.py
 @@ -268,7 +268,7 @@ class DatabaseCreation(BaseDatabaseCreation):
  """
  try:
  # Statement can fail when acceptable_ora_err is not None
 -allow_quiet_fail = acceptable_ora_err is not None and
 len(acceptable_ora_err) > 0
 +allow_quiet_fail = bool(acceptable_ora_err)
  self._execute_statements(cursor, statements, parameters,
 verbosity, allow_quiet_fail=allow_quiet_fa
  return True
  except DatabaseError as err:
 diff --git a/django/db/migrations/questioner.py
 b/django/db/migrations/questioner.py
 --- a/django/db/migrations/questioner.py
 +++ b/django/db/migrations/questioner.py
 @@ -85,7 +85,7 @@ class
 InteractiveMigrationQuestioner(MigrationQuestioner):
  result = input("%s " % question)
  if not result and default is not None:
  return default
 -while len(result) < 1 or result[0].lower() not in "yn":
 +while not result or result[0].lower() not in "yn":
  result = input("Please answer yes or no: ")
  return result[0].lower() == "y"

 diff --git a/django/db/models/base.py b/django/db/models/base.py
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -736,7 +736,7 @@ class Model(metaclass=ModelBase):
  """
  using = using or router.db_for_write(self.__class__,
 instance=self)
  assert not (force_insert and (force_update or update_fields))
 -assert update_fields is None or len(update_fields) > 0
 +assert update_fields is None or update_fields
  cls = origin = self.__class__
  # Skip proxies, but keep the origin as the proxy model.
  if cls._meta.proxy:
 }}}

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

Re: [Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)


Comment:

 Personally, I think it has some readability benefits, at least in some
 places.

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

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)
 * stage:  Unreviewed => Ready for checkin


Comment:

 [https://github.com/django/django/pull/9398 PR] from the patch.

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

[Django] #28862: Error in auto-generated migration

[Django]

#28862: Error in auto-generated migration
-+-
   Reporter:  elros  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.9
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  models migrations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In Django 1.9.11, after deleting a model field and removing it from
 `index_together` attribute, the `makemigrations` command generates a
 broken migration code with RemoveField operation preceding
 AlterIndexTogether operation. That causes the following `migrate` command
 to raise an exception while trying to apply the generated migration.

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

Re: [Django] #28856: GenericForeignKey attributes create new instances on every access

[Django]

#28856: GenericForeignKey attributes create new instances on every access
--+
 Reporter:  Morgan Wahl   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.10
 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):

 I don't think this merits another Django 1.10 release considering that
 supports ends December 1. If they care about security, most users should
 have upgraded to Django 1.11 by now.

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

Re: [Django] #28856: GenericForeignKey attributes create new instances on every access

[Django]

#28856: GenericForeignKey attributes create new instances on every access
--+
 Reporter:  Morgan Wahl   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.10
 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 Morgan Wahl):

 Could the backport fix be applied to 1.10 as well? Is **is** still
 supported, and this is a potential data loss scenario.

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

[Django] #28861: Add schema tests for CIText fields

[Django]

#28861: Add schema tests for CIText fields
+
   Reporter:  Tim Graham|  Owner:  (none)
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.postgres  |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 |
+
 A test for the schemas portion of #28702
 (f0a68c25118786d47041d0a435b2afa953be3c86) was omitted due to some
 [https://github.com/django/django/pull/9291#issuecomment-344425758 test
 suite difficulties]. The original patch is attached but
 [https://github.com/django/django/pull/9291#issuecomment-344462935 some
 refactoring is needed].

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

Re: [Django] #28861: Add schema tests for CIText fields

[Django]

#28861: Add schema tests for CIText fields
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * Attachment "28861.diff" added.


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.c93331846180f9d230e28e45cdac65d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * Attachment "less-len.patch" 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/072.1d469634507a41114e44a8f0d0006931%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28860: Reduce calls to len()

[Django]

#28860: Reduce calls to len()
+
   Reporter:  Дилян Палаузов|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 {{{if len(x)}}} is the same as {{{if x}}} except when {{{len()}}} is
 supposed to throw exception when {{{x}}} is not iterable.

 {{{len(x)}}} can return either zero or a positive integer, hence {{{if
 len(x) < 1}}} is the same as {{{if len(x) == 0}}} <=> {{{if not x}}}.

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

Re: [Django] #28702: Querying CIText fields should use ::citext type cast

[Django]

#28702: Querying CIText fields should use ::citext type cast
-+-
 Reporter:  Дилян Палаузов   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  citext postgres  | Triage Stage:  Accepted
  cast   |
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:"3545e844885608932a692d952c12cd863e2320b5" 3545e844]:
 {{{
 #!CommitTicketReference repository=""
 revision="3545e844885608932a692d952c12cd863e2320b5"
 [1.11.x] Fixed #28702 -- Made query lookups for CIText fields use citext.

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

Re: [Django] #28702: Querying CIText fields should use ::citext type cast

[Django]

#28702: Querying CIText fields should use ::citext type cast
-+-
 Reporter:  Дилян Палаузов   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  citext postgres  | Triage Stage:  Accepted
  cast   |
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:"4d3b8e199ec00a0aba111637a25f5abcaf3d6dfc" 4d3b8e19]:
 {{{
 #!CommitTicketReference repository=""
 revision="4d3b8e199ec00a0aba111637a25f5abcaf3d6dfc"
 [2.0.x] Fixed #28702 -- Made query lookups for CIText fields use citext.

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

Re: [Django] #28702: Querying CIText fields should use ::citext type cast

[Django]

#28702: Querying CIText fields should use ::citext type cast
-+-
 Reporter:  Дилян Палаузов   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.11
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  citext postgres  | Triage Stage:  Accepted
  cast   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * owner:  (none) => Tim Graham 
 * resolution:   => fixed


Comment:

 In [changeset:"f0a68c25118786d47041d0a435b2afa953be3c86" f0a68c2]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0a68c25118786d47041d0a435b2afa953be3c86"
 Fixed #28702 -- Made query lookups for CIText fields use citext.
 }}}

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

Re: [Django] #28692: QuerySet.bulk_create() combine with select/prefetch_related()

[Django]

#28692: QuerySet.bulk_create() combine with select/prefetch_related()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bulk_create  | Triage Stage:  Accepted
  select_related prefetch_related|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 I guess a patch will be provided for prefetch_related() once #28600 gets
 integrated, as stated in the fourth comment of that 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/072.f9ed4e36c231a1793e8f6bd1b1c596d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28859: Django hides exception from database with Oracle backend.

[Django]

#28859: Django hides exception from database with Oracle backend.
-+-
 Reporter:  Jani Tiainen |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jani Tiainen):

 * Attachment "django-oracle-bug.tar.gz" added.

 Minimal project to demonstrate the problem

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

[Django] #28859: Django hides exception from database with Oracle backend.

[Django]

#28859: Django hides exception from database with Oracle backend.
-+-
   Reporter:  Jani   |  Owner:  nobody
  Tiainen|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  oracle
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Attached minimal project to demonstrate the problem.

 Traceback from Django:
 {{{
 Traceback (most recent call last):
   File "/home/jtiai/projects/django-oracle-
 bug/django_oracle_bug/django_oracle_bug/tests.py", line 6, in
 test_trigger_failure
 obj = MyModel.objects.create()
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/query.py", line 394, in create
 obj.save(force_insert=True, using=self.db)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/base.py", line 808, in save
 force_update=force_update, update_fields=update_fields)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/base.py", line 838, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/base.py", line 924, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/base.py", line 963, in _do_insert
 using=using, raw=raw)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/manager.py", line 85, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/query.py", line 1076, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/models/sql/compiler.py", line 1114, in execute_sql
 return self.connection.ops.fetch_returned_insert_id(cursor)
   File "/home/jtiai/.pyenv/versions/django-oracle-bug/lib/python3.6/site-
 packages/django/db/backends/oracle/operations.py", line 245, in
 fetch_returned_insert_id
 return int(cursor._insert_id_var.getvalue())
 TypeError: int() argument must be a string, a bytes-like object or a
 number, not 'NoneType'
 }}}

 Real error that happend:
 {{{
 ORA-01403: no data found
 ORA-06512: at "ORA_TEST.TG_FAILING", line 4
 ORA-04088: error during execution of trigger 'ORA_TEST.TG_FAILING'
 }}}

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

Re: [Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * Attachment "no-else-after-return.patch" 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/072.f874f21766bb71ea22e1f7ef535f8fe0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28858: Remove 'else' after 'return' or 'raise'

[Django]

#28858: Remove 'else' after 'return' or 'raise'
+
   Reporter:  Дилян Палаузов|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 ... as it has no added value.

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

Re: [Django] #28857: Cast function may generate invalid SQL on PostgreSQL for complex expressions

[Django]

#28857: Cast function may generate invalid SQL on PostgreSQL for complex
expressions
-+-
 Reporter:  Jurica Železnjak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,orm | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jurica Železnjak):

 Replying to [comment:3 Tim Graham]:
 > It looks like parentheses could also be added to
 `ObjectAtPath.template`. Can you reproduce the problem with any of the
 built-in database functions? With either solution, it seems like
 unnecessary parenthesis would be present in some cases. It would be nice
 to avoid that if possible.

 True, but that's not the point. The point is that with the default
 implementation of Cast function it would work fine always, but with the
 overridden postgresql-specific it does not.
 ObjectAtPath does its own thing like it should - fetches a value by key
 from JSON field.

 {{{
 def as_postgresql(self, compiler, connection):
 # CAST would be valid too, but the :: shortcut syntax is more
 readable.
 return self.as_sql(compiler, connection,
 template='%(expressions)s::%(db_type)s')
 }}}

 But the reasoning for the built-in shortcut postgresql-specific method is
 that it would be more readable - while that's true - it leads to the
 mentioned problem.

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

Re: [Django] #28486: Template FileLoader can't find widget templates

[Django]

#28486: Template FileLoader can't find widget templates
-+-
 Reporter:  Andrey   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  widgets, templates,  | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Federico Capoano):

 Hi,

 I just stumbled upon this issue and found the solution thanks to this
 ticket, therefore thank you very much for pointing out the solution.

 However, I wonder why the behaviour that I expected (which I believe also
 Andrey expected and anyone with a good experience with django would
 expect) cannot be set as the default one.
 Is it a backward compatibility issue, or what?

 Best regards
 Federico Capoano

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

Re: [Django] #28120: CharField: if max_length=True (or False): makemigrations generates a migration and migrate fails

[Django]

#28120: CharField: if max_length=True (or False): makemigrations generates a
migration and migrate fails
-+-
 Reporter:  Carles Pina Estany   |Owner:  Carles
 |  Pina Estany
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 What about ensuring that max_length is an int, and not bool this way:
 {{{
 diff --git a/django/db/models/fields/__init__.py
 b/django/db/models/fields/__init__.py
 --- a/django/db/models/fields/__init__.py
 +++ b/django/db/models/fields/__init__.py
 @@ -1045,8 +1045,7 @@ class CharField(Field):
  id='fields.E120',
  )
  ]
 -elif (not isinstance(self.max_length, int) or
 isinstance(self.max_length, bool) or
 -self.max_length <= 0):
 +elif type(self.max_length) != int or self.max_length <= 0:
  return [
  checks.Error(
  "'max_length' must be a positive integer.",

 }}}

 There are more places in the code that check for {{{not isinstance(...,
 int)}}}.

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

Re: [Django] #28857: Cast function may generate invalid SQL on PostgreSQL for complex expressions (was: PostgreSQL Cast function shortcut)

[Django]

#28857: Cast function may generate invalid SQL on PostgreSQL for complex
expressions
-+-
 Reporter:  Jurica Železnjak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,orm | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Old description:

> In some cases when using the shortcut notation "::" the database gives an
> error.
>
> GOOD:
>   CAST("sensors_sensordata"."data" #>> '{Temperature}' AS DOUBLE
> PRECISION) AS "temp"
>
> ERROR:
>   "sensors_sensordata"."data" #>> '{Temperature}'::DOUBLE PRECISION AS
> "temp"
>
> I've got a response from Postgre people and they've said:
> --
> The precedence between the two is different.  The equivalent would be:
>
>   ("sensors_sensordata"."data" #>> '{Temperature}')::DOUBLE PRECISION
>
> In other words, not a bug.
> 
>
> So it seems the as_postgresql method needs to wrap the expression into
> parenthesis.
> https://docs.djangoproject.com/en/1.11/_modules/django/db/models/functions/base/#Cast

New description:

 In some cases when using the shortcut notation "::", the database gives an
 error.

 GOOD: `CAST("sensors_sensordata"."data" #>> '{Temperature}' AS DOUBLE
 PRECISION) AS "temp"`

 ERROR: `"sensors_sensordata"."data" #>> '{Temperature}'::DOUBLE PRECISION
 AS "temp"`

 I've got a response from PostgreSQL people and they've said:

  The precedence between the two is different.  The equivalent would be:
  `("sensors_sensordata"."data" #>> '{Temperature}')::DOUBLE PRECISION`
  In other words, not a bug.

 So it seems the `as_postgresql()` method needs to wrap the expression into
 parenthesis.
 
https://docs.djangoproject.com/en/1.11/_modules/django/db/models/functions/base/#Cast

--

Comment (by Tim Graham):

 It looks like parentheses could also be added to `ObjectAtPath.template`.
 Can you reproduce the problem with any of the built-in database functions?
 With either solution, it seems like unnecessary parenthesis would be
 present in some cases. It would be nice to avoid that if possible.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.e3d54313138caf9e4f9239e4e593f438%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28839: Model.__repr__() should include the pk

[Django]

#28839: Model.__repr__() should include the pk
-+-
 Reporter:  Álex Córcoles|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 Tim Graham):

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


Comment:

 The place to revisit the decision would be on the
 [https://groups.google.com/d/topic/django-
 developers/7Jqzwg5nt-c/discussion django-developers thread]. Comments in
 this ticket tracker don't reach a wide audience.

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

Re: [Django] #28857: PostgreSQL Cast function shortcut

[Django]

#28857: PostgreSQL Cast function shortcut
-+-
 Reporter:  Jurica Železnjak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,orm | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jurica Železnjak):

 models.py
 {{{
 from django.contrib.postgres.fields import JSONField

 class SensorData(BaseModel):
 timestamp = models.DateTimeField()
 data = JSONField()

 """ sample value for data: {
   "Temperature": 19.9,
   "Relative Humidity": 29.4,
   "PM2.5": 9.8,
   "TVOC": 79.0,
   "CO2": 476.0,
   "CO": 0.0,
   "Air Pressure": 977.1,
   "Ozone": 21.3,
   "NO2": 68.1,
   "Timestamp": 1511770361,
   "DateTime": "2017-11-27 09:12"
 }
 """
 }}}

 {{{
 from django.db.models.functions import Cast
 from django.db.models import Func, Avg, FloatField

 class ObjectAtPath(Func):
 function = '#>>'
 template = "%(expressions)s%(function)s'{%(path)s}'"
 arity = 1

 def __init__(self, expression, path, **extra):
 # if path is a list, convert it to a comma separated string
 if isinstance(path, (list, tuple)):
 path = ','.join(path)

 super().__init__(expression, path=path, **extra)


 SensorData.objects.all().aggregate(temp=Avg(Cast(ObjectAtPath('data',
 'Temperature'), output_field=FloatField(
 }}}


 I think this should be enough to reproduce the error.

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

Re: [Django] #28857: PostgreSQL Cast function shortcut

[Django]

#28857: PostgreSQL Cast function shortcut
-+-
 Reporter:  Jurica Železnjak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres,orm | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Please provide steps to reproduce the problem.

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

Re: [Django] #28839: Model.__repr__() should include the pk

[Django]

#28839: Model.__repr__() should include the pk
-+-
 Reporter:  Álex Córcoles|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 Álex Córcoles):

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


Comment:

 Sorry again, after taking a look at the implementation, I disagree
 slightly; the PK should be included in `repr`, not `str`. It's nice to
 have a default repr implementation with the PK for use in the shell et
 al., but str is used for stuff such as choosing the displayed str on a
 dropdown- where I think a PK is out of place...

 (You might close this again if you guys disagree- I'm OK with that, but I
 wanted to make my full 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/065.523c8eef0562faa1cf6151225ae67cea%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28857: PostgreSQL Cast function shortcut

[Django]

#28857: PostgreSQL Cast function shortcut
-+-
   Reporter:  jzelez |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  postgres,orm
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 In some cases when using the shortcut notation "::" the database gives an
 error.

 GOOD:
   CAST("sensors_sensordata"."data" #>> '{Temperature}' AS DOUBLE
 PRECISION) AS "temp"

 ERROR:
   "sensors_sensordata"."data" #>> '{Temperature}'::DOUBLE PRECISION AS
 "temp"

 I've got a response from Postgre people and they've said:
 --
 The precedence between the two is different.  The equivalent would be:

   ("sensors_sensordata"."data" #>> '{Temperature}')::DOUBLE PRECISION

 In other words, not a bug.
 

 So it seems the as_postgresql method needs to wrap the expression into
 parenthesis.
 
https://docs.djangoproject.com/en/1.11/_modules/django/db/models/functions/base/#Cast

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

Re: [Django] #22406: Inconsistent way to parse boolean value from posted data

[Django]

#22406: Inconsistent way to parse boolean value from posted data
--+--
 Reporter:  xiaowl@…  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  1.6
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Christian Kreuzberger):

 A similar inconsistency still exists with BooleanFields and
 NullBooleanFields in django.forms:


 django.forms.fields.BooleanField has the following logic:
 {{{
 #!python

 class BooleanField(Field):
 widget = CheckboxInput

 def to_python(self, value):
 """Returns a Python boolean object."""
 # Explicitly check for the string 'False', which is what a hidden
 field
 # will submit for False. Also check for '0', since this is what
 # RadioSelect will provide. Because bool("True") == bool('1') ==
 True,
 # we don't need to handle that explicitly.
 if isinstance(value, six.string_types) and value.lower() in
 ('false', '0'):
 value = False
 else:
 value = bool(value)
 return super(BooleanField, self).to_python(value)
 }}}

 So 'false', 'False',false,'0' will be evaluated to False,
 'true','True',true,'1' will be evaluated to True. I guess '2' and '3' will
 not be converted and will be evaluated as None at this point.

 django.forms.fields.NullBooleanField has a different implementation:
 {{{
 #!python
 class NullBooleanField(BooleanField):
 """
 A field whose valid values are None, True and False. Invalid values
 are
 cleaned to None.
 """
 widget = NullBooleanSelect

 def to_python(self, value):
 """
 Explicitly checks for the string 'True' and 'False', which is what
 a
 hidden field will submit for True and False, for 'true' and
 'false',
 which are likely to be returned by JavaScript serializations of
 forms,
 and for '1' and '0', which is what a RadioField will submit.
 Unlike
 the Booleanfield we need to explicitly check for True, because we
 are
 not using the bool() function
 """
 if value in (True, 'True', 'true', '1'):
 return True
 elif value in (False, 'False', 'false', '0'):
 return False
 else:
 return None
 }}}


 Essentially, the to_python method will do the same as BooleanFields
 to_python method, but now comes the funny part:

 NullBooleanField uses the NullBooleanSelect widget, while BooleanField
 uses the CheckboxInput widget:

 BooleanField uses django.forms.widget.CheckboxInput which evaluates
 'true','True',True,'1' to True, and 'false','False',False,'0' to False -
 which is fine.

 {{{
 #!python

 class CheckboxInput(Input):
 def value_from_datadict(self, data, files, name):
 if name not in data:
 # A missing value means False because HTML form submission
 does not
 # send results for unselected checkboxes.
 return False
 value = data.get(name)
 # Translate true and false strings to boolean values.
 values = {'true': True, 'false': False}
 if isinstance(value, six.string_types):
 value = values.get(value.lower(), value)
 return bool(value)
 }}}


 But NullBooleanField uses NullBooleanSelect, which as stated above, does
 NOT evaluate 'false' to False, and not 'true' to True. Instead, it
 evalutes '2' and 'True' to True, '3' and 'False' to False...

 {{{
 #!python
 class NullBooleanSelect(Select):
 """
 A Select Widget intended to be used with NullBooleanField.
 """
 def __init__(self, attrs=None):
 choices = (
 ('1', ugettext_lazy('Unknown')),
 ('2', ugettext_lazy('Yes')),
 ('3', ugettext_lazy('No')),
 )
 super(NullBooleanSelect, self).__init__(attrs, choices)

 def format_value(self, value):
 try:
 return {True: '2', False: '3', '2': '2', '3': '3'}[value]
 except KeyError:
 return '1'

 def value_from_datadict(self, data, files, name):
 value = data.get(name)
 return {
 '2': True,
 True: True,
 'True': True,
 '3': False,
 'False': False,
 False: False,
 }.get(value)
 }}}


 Because of this inconsistency, we are experiencing a very funny behaviour
 for NullBooleanField:

 django.forms.forms.BaseForm has the _clean_fields method, which calls the
 widgets `value_from_datadict` method:
 `value =