Re: [Django] #25253: MySQL migrations drop & recreate constraints unnecessarily when changing attributes that don't affect the schema

2017-10-21 Thread Django 
#25253: MySQL migrations drop & recreate constraints unnecessarily when changing
attributes that don't affect the schema
--+
 Reporter:  Thomas Recouvreux |Owner:  Shun Yu
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:  migrations m2m mysql  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Shun Yu):

 I have a pull request: https://github.com/django/django/pull/9269

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

Re: [Django] #28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last

2017-10-21 Thread Django 
#28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last
-+-
 Reporter:  Tomer Chachamu   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e98ae4fe6bc1baa402b10bc379d2e96b79bbb3b0" e98ae4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="e98ae4fe6bc1baa402b10bc379d2e96b79bbb3b0"
 [1.11.x] Fixed #28722 -- Made QuerySet.reverse() affect
 nulls_first/nulls_last.

 Backport of 21a3a29dc9d138c248fd7922923b3ec710735c6c 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/063.6be093f4b5b22d0e5804ce1508383838%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last

2017-10-21 Thread Django 
#28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last
-+-
 Reporter:  Tomer Chachamu   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"21a3a29dc9d138c248fd7922923b3ec710735c6c" 21a3a29d]:
 {{{
 #!CommitTicketReference repository=""
 revision="21a3a29dc9d138c248fd7922923b3ec710735c6c"
 Fixed #28722 -- Made QuerySet.reverse() affect nulls_first/nulls_last.
 }}}

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

Re: [Django] #28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last

2017-10-21 Thread Django 
#28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last
-+-
 Reporter:  Tomer Chachamu   |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"57d46606edd29880e7852a9ee86a77a96f4d0b3a" 57d46606]:
 {{{
 #!CommitTicketReference repository=""
 revision="57d46606edd29880e7852a9ee86a77a96f4d0b3a"
 [2.0.x] Fixed #28722 -- Made QuerySet.reverse() affect
 nulls_first/nulls_last.

 Backport of 21a3a29dc9d138c248fd7922923b3ec710735c6c 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/063.9aecdc4d1b436db2ee5fd844fb6343f3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28704: update_or_create() calls select_for_update(), which locks database row

2017-10-21 Thread Django 
#28704: update_or_create() calls select_for_update(), which locks database row
-+-
 Reporter:  Rafal Radulski   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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 Rafal Radulski):

 I thought that a call to `select_for_update` was problematic, but I was
 wrong. Thank you for the explanation.

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

Re: [Django] #28721: Cannot use the variable name "inf" in templates

2017-10-21 Thread Django 
#28721: Cannot use the variable name "inf" in templates
-+--
 Reporter:  Fraser Nevett|Owner:  Levi Payne
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham):

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


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

Re: [Django] #28721: Cannot use the variable name "inf" in templates

2017-10-21 Thread Django 
#28721: Cannot use the variable name "inf" in templates
-+--
 Reporter:  Fraser Nevett|Owner:  Levi Payne
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tim Graham ):

 In [changeset:"6c3104221b2cb9f068c07adf3ef24c9f49627834" 6c31042]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c3104221b2cb9f068c07adf3ef24c9f49627834"
 Refs #28721 -- Added test for variations of 'inf'/'infinity' as a template
 variable names.

 Fixed by 9ec7d8e514e09636b0ab4bcac74b5f7a5be335a3.
 }}}

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

Re: [Django] #28693: DisallowedHost can cause uncaught exception and HTTP 500

2017-10-21 Thread Django 
#28693: DisallowedHost can cause uncaught exception and HTTP 500
+
 Reporter:  Greg Price  |Owner:  (none)
 Type:  Bug |   Status:  new
Component:  HTTP handling   |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  DisallowedHost  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tomer Chachamu):

 * cc: Tomer Chachamu (added)
 * owner:  Tomer Chachamu => (none)
 * has_patch:  0 => 1
 * status:  assigned => new
 * component:  Uncategorized => HTTP handling


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

Re: [Django] #28693: DisallowedHost can cause uncaught exception and HTTP 500

2017-10-21 Thread Django 
#28693: DisallowedHost can cause uncaught exception and HTTP 500
+--
 Reporter:  Greg Price  |Owner:  Tomer Chachamu
 Type:  Bug |   Status:  assigned
Component:  Uncategorized   |  Version:  1.11
 Severity:  Normal  |   Resolution:
 Keywords:  DisallowedHost  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tomer Chachamu):

 * owner:  nobody => Tomer Chachamu
 * status:  new => assigned
 * stage:  Unreviewed => Accepted


Comment:

 There would need to be a deprecation path for custom 400 views that are
 using csrf tokens, so I think catching DisallowedHost in  the traceback is
 the right answer here.

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

Re: [Django] #28717: Admin always queries default database when rendering a list_filter on a ForeignKey

2017-10-21 Thread Django 
#28717: Admin always queries default database when rendering a list_filter on a
ForeignKey
---+--
 Reporter:  Adam Brenecki  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  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 Tomer Chachamu):

 Yep, that's an oversight in the documentation. However, you can remove the
 admin customisation and write a database router instead. That will work
 not just for the admin but throughout your website too. If you are setting
 `request.applyol` in middleware, you can in the same middleware tell your
 database router to change the database that it should give for
 `db_for_read(model=ApplyOl)`. Here's an example you can adapt:
 
https://github.com/yandex/django_replicated/blob/master/django_replicated/router.py

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

Re: [Django] #28704: update_or_create() calls select_for_update(), which locks database row

2017-10-21 Thread Django 
#28704: update_or_create() calls select_for_update(), which locks database row
-+-
 Reporter:  Rafal Radulski   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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 Tomer Chachamu):

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


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

Re: [Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-10-21 Thread Django 
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
 Reporter:  Tom van Bussel   |Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-

Comment (by Tomer Chachamu):

 Thanks for the bug report.

 What did you expect to be the value of `x[0].test_name`?

 We don't have any documentation on how a `Q(**kwargs)` object behaves when
 `len(kwargs) == 0`, and we have no tests for it. Perhaps it should be
 raising an exception (or initially a deprecation warning).

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

Re: [Django] #28567: Unclear documentation for 'next' parameter of set_language view

2017-10-21 Thread Django 
#28567: Unclear documentation for 'next' parameter of set_language view
--+
 Reporter:  George Tantiras   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tomer Chachamu):

 Here are some passing tests showing how the view will behave when you have
 set `next` correctly.

 {{{#!python
 @override_settings(
 USE_I18N=True,
 LANGUAGES=[
 ('en', 'English'),
 ('fr', 'French'),
 ('de', 'German'),
 ],
 MIDDLEWARE=[
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.middleware.common.CommonMiddleware',
 ],
 ROOT_URLCONF='i18n.i18n_unprefixed_urls',
 LANGUAGE_CODE='en',
 )
 class UnprefixedI18nSetLang(TestCase):
 def test_en2fr(self):
 self.client.post('/i18n/setlang/', data={'language': 'en'})
 response = self.client.post(
 '/i18n/setlang/',
 data={'language': 'fr', 'next': '/admin/'},
 follow=True,
 )
 self.assertEqual(
 response.redirect_chain,
 [('/fr/admin/', 302), ('/fr/admin/login/?next=/fr/admin/',
 302)]
 )

 def test_fr2en(self):
 self.client.post('/i18n/setlang/', data={'language': 'fr'})
 response = self.client.post(
 '/i18n/setlang/',
 data={'language': 'en', 'next': '/admin/'},
 follow=True,
 )
 self.assertEqual(
 response.redirect_chain,
 [('/admin/', 302), ('/admin/login/?next=/admin/', 302)]
 )

 def test_fr2de(self):
 self.client.post('/i18n/setlang/', data={'language': 'fr'})
 response = self.client.post(
 '/i18n/setlang/',
 data={'language': 'de', 'next': '/admin/'},
 follow=True,
 )
 self.assertEqual(
 response.redirect_chain,
 [('/de/admin/', 302), ('/de/admin/login/?next=/de/admin/',
 302)]
 )
 }}}

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

Re: [Django] #28567: Unclear documentation for 'next' parameter of set_language view (was: Set Language Redirect View -> 404 if prefix_default_language=False)

2017-10-21 Thread Django 
#28567: Unclear documentation for 'next' parameter of set_language view
--+
 Reporter:  George Tantiras   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tomer Chachamu):

 * owner:  Tomer Chachamu => (none)
 * needs_docs:  0 => 1
 * status:  assigned => new
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for that test, it really clarified it.

 In the HTML in the documentation you mentioned, it mentions the
 `redirect_to` context variable, but doesn't really explain what to set it
 to. In your case, it is empty, so the `set_language` view has started
 looking at the `HTTP_REFERRER` as shown in your tests.

 You need to set `redirect_to` to the current page URL, without the
 language prefix. For example, you could add this context processor to your
 settings:

 {{{#!python
 from django.urls import translate_url

 def redirect_path_context_processor(request):
 return {'language_select_redirect_to': translate_url(request.path,
 settings.LANGUAGE_CODE)}
 }}}

 The `set_language` view will then translate the URL again to the user's
 selected language.

 Also, if you *do* use `prefix_default_language=True`, then the URL for the
 set_language view should also be prefixed. I don't think this is
 documented anywhere.

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

Re: [Django] #28567: Set Language Redirect View -> 404 if prefix_default_language=False

2017-10-21 Thread Django 
#28567: Set Language Redirect View -> 404 if prefix_default_language=False
-+-
 Reporter:  George Tantiras  |Owner:  Tomer
 |  Chachamu
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Tomer Chachamu):

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

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

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

Comment (by Tomer Chachamu):

 https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-
 features/

 > First request the feature on the django-developers list, not in the
 ticket tracker. It’ll get read more closely if it’s on the mailing list.
 This is even more important for large-scale feature requests. We like to
 discuss any big changes to Django’s core on the mailing list before
 actually working on them.

 Please send the feature request again to the mailing list. However, here's
 my opinion:

 I don't think it will be possible to implement `select_related` as the
 behaviour of `INSERT .. RETURNING ..` varies a lot between databases. It
 would be possible to implement `prefetch_related`.

 There are already two ways to reduce the number of queries, is either good
 for you? One is:

 {{{#!python
 from django.db.models import prefetch_related_objects
 new_objects = [ModelA(..., b_id=3), ModelA(..., b_id=4), ModelA(...,
 b_id=5)]
 ModelA.objects.bulk_create(new_objects)
 prefetch_related_objects(new_objects, 'b')
 for m in new_objects:
 print m.b.description
 }}}

 Another is setting the `b` attribute on your models, instead of `b_id`

 {{{#!python
 bs_by_id = ModelB.objects.in_bulk(relevant_b_ids)
 new_objects = [ModelA(..., b=bs_by_id[3]), ModelA(..., b=bs_by_id[4]),
 ModelA(..., b=bs_by_id[5])]
 ModelA.objects.bulk_create(new_objects)
 for m in new_objects:
 print m.b.description
 }}}

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

Re: [Django] #28704: update_or_create() calls select_for_update(), which locks database row

2017-10-21 Thread Django 
#28704: update_or_create() calls select_for_update(), which locks database row
-+-
 Reporter:  Rafal Radulski   |Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-

Comment (by Tomer Chachamu):

 I'm assuming you're passing something in `defaults`, right?

 `update_or_create` currently calls `Model.save` and you are suggesting it
 should call `QuerySet.update` instead. Both of them send `UPDATE` SQL
 statements to the database. That will create a row-level lock. In
 Postgres, the lock level is either `FOR UPDATE` or `FOR NO KEY UPDATE`,
 see https://www.postgresql.org/docs/9.6/static/explicit-locking.html
 #LOCKING-ROWS.

 But, neither of these locks will block an ordinary `SELECT` statement like
 the `.get()` in the second transaction.

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

Re: [Django] #28705: Wrong annotation when used with QuerySet.order_by()

2017-10-21 Thread Django 
#28705: Wrong annotation when used with QuerySet.order_by()
-+-
 Reporter:  Rafael Capucho   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Annotate, ORM,   | Triage Stage:
  Order_by   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tomer Chachamu):

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


Comment:

 Also, if you can provide the output that you expected for each of the
 queries, that would help us understand the issue :)

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

Re: [Django] #28705: Wrong annotation when used with QuerySet.order_by()

2017-10-21 Thread Django 
#28705: Wrong annotation when used with QuerySet.order_by()
-+-
 Reporter:  Rafael Capucho   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotate, ORM,   | Triage Stage:
  Order_by   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tomer Chachamu):

 It looks like this section explains the behaviour:
 https://docs.djangoproject.com/en/1.11/topics/db/aggregation/#interaction-
 with-default-ordering-or-order-by

 Maybe you want to use `.annotate(...).order_by('label', 'latest')`
 instead?

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

Re: [Django] #28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last

2017-10-21 Thread Django 
#28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last
-+-
 Reporter:  Tomer Chachamu   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tomer Chachamu):

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

Re: [Django] #28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last

2017-10-21 Thread Django 
#28722: QuerySet.reverse() doesn't reverse nulls_first/nulls_last
-+-
 Reporter:  Tomer Chachamu   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Tomer Chachamu):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Unreviewed


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

Re: [Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-10-21 Thread Django 
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
 Reporter:  Tom van Bussel   |Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-
Description changed by Tom van Bussel:

Old description:

> The following code causes an OperationError:
> {{{
> q = Q() # Dynamically constructed, possibly empty
> x = TestModel.objects.annotate(test_name=When(q, then=Value(True)),
> default=Value(False), output_field=BooleanField())).all()
> print(x)
> }}}
> The code above results in a SQL query which contains {{{CASE WHEN
> THEN}}}, with nothing between the WHEN and THEN.

New description:

 The following code causes an OperationError:
 {{{
 q = Q() # Dynamically constructed, possibly empty
 x = TestModel.objects.annotate(test_name=Case(When(q, then=Value(True)),
 default=Value(False), output_field=BooleanField())).all()
 print(x)
 }}}
 The code above results in a SQL query which contains {{{CASE WHEN
 THEN}}}, with nothing between the WHEN and THEN.

--

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

[Django] #28731: Passing an empty Q() to a When inside a Case causes an OperationError

2017-10-21 Thread Django 
#28731: Passing an empty Q() to a When inside a Case causes an OperationError
-+-
   Reporter:  Tom van|  Owner:  nobody
  Bussel |
   Type:  Bug| Status:  new
  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  |
-+-
 The following code causes an OperationError:
 {{{
 q = Q() # Dynamically constructed, possibly empty
 x = TestModel.objects.annotate(test_name=When(q, then=Value(True)),
 default=Value(False), output_field=BooleanField())).all()
 print(x)
 }}}
 The code above results in a SQL query which contains {{{CASE WHEN
 THEN}}}, with nothing between the WHEN and THEN.

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

Re: [Django] #28730: Large integer literals lose precision in templates

2017-10-21 Thread Django 
#28730: Large integer literals lose precision in templates
-+-
 Reporter:  Fraser Nevett|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 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
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"9ec7d8e514e09636b0ab4bcac74b5f7a5be335a3" 9ec7d8e]:
 {{{
 #!CommitTicketReference repository=""
 revision="9ec7d8e514e09636b0ab4bcac74b5f7a5be335a3"
 Fixed #28730 -- Fixed loss of precision for large integer literals in
 templates

 Thanks Fraser Nevett for the report and Tim Graham for patch edits.
 }}}

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

Re: [Django] #28730: Large integer literals lose precision in templates

2017-10-21 Thread Django 
#28730: Large integer literals lose precision in templates
-+-
 Reporter:  Fraser Nevett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #28730: Large integer literals lose precision in templates

2017-10-21 Thread Django 
#28730: Large integer literals lose precision in templates
-+
 Reporter:  Fraser Nevett|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Claude Paroz):

 * has_patch:  0 => 1
 * version:  1.11 => master


Comment:

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

Re: [Django] #28727: sqlite: CAST to DATE causes error

2017-10-21 Thread Django 
#28727: sqlite: CAST to DATE causes error
-+-
 Reporter:  direx|Owner:  nobody
 Type:  Bug  |   Status:  new
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 direx):

 Replying to [comment:4 Simon Charette]:
 > I managed to reproduce locally but I'm not sure what the resolution
 should be here. I feel like this is an abuse of the `Cast` function as it
 wasn't meant to be used with Python primitives, `Value` should be used
 instead.

 In the Django docs it is expicitely stated that `Cast` is required in
 combination with Python types and `Coalesce`. It says:

 ''A Python value passed to Coalesce on MySQL may be converted to an
 incorrect type unless explicitly cast to the correct database type''

 See the example right here:

 https://docs.djangoproject.com/en/1.11/ref/models/database-
 functions/#coalesce

 The code in the given example does not work on SQLite and triggers this
 very bug, so I think this is a valid issue for all current Django
 versions.

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