date:20171002

Re: [Django] #28670: django/db/backends/oracle/compiler.py handling of LIMIT+OFFSET could be better in Oracle 12+.

2017-10-02 Thread Django

#28670: django/db/backends/oracle/compiler.py handling of LIMIT+OFFSET could be
better in Oracle 12+.
-+-
 Reporter:  Markus Stenberg  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  2.0 => master
 * 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.ec013ddae69847c60b649e1ebd5d3be9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28636: Allow customizing the fallback language from the locale middleware (was: Translation module: Check `LANG_INFO` against user's language preference as optional feature)

2017-10-02 Thread Django

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

 * version:  1.11 => master
 * stage:  Unreviewed => Accepted
 * needs_tests:  0 => 1


Comment:

 Thanks for testing, I'll made a pull request soon.

 However, are you sure you need that special `process_request` method? What
 about simply:
 {{{
 class CustomLocaleMiddleWare(LocaleMiddleware):
 fallback_language = 'en'
 }}}

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

Re: [Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

2017-10-02 Thread Django

#28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) 
returns
False
-+-
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Duplicate of #25571; fixed in Django 1.10. To avoid wasting ticket triager
 time, please verify issues affect master (or at least the latest release
 version) rather than reporting against old 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/068.ae04484c3cc516be38368cbea373645d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

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

2017-10-02 Thread Django

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom  |Owner:  Tom
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom):

 * has_patch:  0 => 1


Comment:

 Initial PR: https://github.com/django/django/pull/9192

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

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

Re: [Django] #28636: Translation module: Check `LANG_INFO` against user's language preference as optional feature

2017-10-02 Thread Django

#28636: Translation module: Check `LANG_INFO` against user's language 
preference as
optional feature
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Denis Anuschewski):

 Thx again. I tested your code and it really does exactly what I want!

 You were right that I don't really need to know the request language if
 it's not in `LANGUAGES`, because the resulting language is always 'en' for
 these cases. So my custom middleware's `process_request` would look like
 this:

 {{{
 def process_request(self, request):
 self.fallback_language = 'en'
 super(CustomMiddleWare, self).process_request(request)
 lan = request.LANGUAGE_CODE
 if not settings.LANGUAGE_CODE.startswith(lan):
 
translation.trans_real.translation(lan).add_fallback(DjangoTranslation(self.fallback_language))
 }}}

 Therefore I get either `LANGUAGE_CODE`, English or a language from
 `LANGUAGES` with English translation fallback. Bingo!

 Your approach seems cleaner and more readable for me, plus it affects less
 code. But there is one little thing I am missing: I would like to see an
 additional paragraph in the docstring  of `get_language_from_request`
 describing what fallback does. I would suggest something like this:

 {{{
 With a given fallback, this value will be returned instead of
 settings.LANGUAGE_CODE if no user language could be found.
 }}}

 Otherwise I am not missing anything. If you make a pull request with the
 little addition I mentioned, I am more than happy to declare it as a fix
 for this bug and vote for it.

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

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-02 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
-+--
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 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):

 Please try to confirm bugs on Django master (or at least on the latest
 released version) instead of reporting bugs for Django 1.8. Django 1.8
 only receives fixes for security and data loss issues at this point.

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

Re: [Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-02 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
-+--
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.8
 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 Dylan Young:

Old description:

> This means that POSTing the form does not submit the accompanying
> selected data.
>
> This seems to be an issue with `attrs={'form': 'theform'}` not being
> passed through to the underlying checkbox inputs.
>
> SelectMultiple behaves as expected (submitting with the form).
>
> Minimal (inefficient) Example (must be included on a page with a form
> named 'theform' to see the problematic POST):
>

> {{{
> class UserSelectForm(Form):
> selected_users = MultipleChoiceField(
> choices=User.objects.all()[0:4],
> initial=User.objects.all()[0:4],
> widget=SelectMultiple(attrs={'form': 'theform'}),
> required=True)
> }}}
>
> Not sure if this is fixed in Django>1.8

New description:

 This means that POSTing the form does not submit the accompanying selected
 data.

 This seems to be an issue with `attrs={'form': 'theform'}` not being
 passed through to the underlying checkbox inputs.

 SelectMultiple behaves as expected (submitting with the form).

 Minimal (inefficient) Example (must be included on a page with a form
 named 'theform' to see the problematic POST):


 {{{
 class UserSelectForm(Form):
 selected_users = MultipleChoiceField(
 choices=[('ex', 'Example'), ('ex2', 'Example2')],
 initial='ex',
 widget=CheckboxSelectMultiple(attrs={'form':
 'theform'}),
 required=True)
 }}}

 Not sure if this is fixed in Django>1.8 as I have found no other reference
 to the bug.

--

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

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

[Django] #28672: CheckboxSelectMultiple does not correctly bind to the form attribute passed in when rendered outside its containing form

2017-10-02 Thread Django

#28672: CheckboxSelectMultiple does not correctly bind to the form attribute 
passed
in when rendered outside its containing form
---+
   Reporter:  Dylan Young  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Forms|Version:  1.8
   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|
---+
 This means that POSTing the form does not submit the accompanying selected
 data.

 This seems to be an issue with `attrs={'form': 'theform'}` not being
 passed through to the underlying checkbox inputs.

 SelectMultiple behaves as expected (submitting with the form).

 Minimal (inefficient) Example (must be included on a page with a form
 named 'theform' to see the problematic POST):


 {{{
 class UserSelectForm(Form):
 selected_users = MultipleChoiceField(
 choices=User.objects.all()[0:4],
 initial=User.objects.all()[0:4],
 widget=SelectMultiple(attrs={'form': 'theform'}),
 required=True)
 }}}

 Not sure if this is fixed in Django>1.8

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

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-02 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-02 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 You're right, thanks. This PR fix also cascade deletion, because it
 affects `Collector.get_del_batches()`, therefore it fix entire ticket
 since `UpdateQuery.update_batch()` works fine even without it.

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

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

2017-10-02 Thread Django

#28671: DateTimeField: make auto_now_add just a default value
-+-
   Reporter:  Дилян  |  Owner:  nobody
  Палаузов   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Providing there is no strong reason to threat auto_now_add as something
 different than a default value, that cannot be overridden, here is a patch
 permitting to set the auto_now_add:

 {{{
 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
 @@ -1272,7 +1272,7 @@ class DateField(DateTimeCheckMixin, Field):
  )

  def pre_save(self, model_instance, add):
 -if self.auto_now or (self.auto_now_add and add):
 +if self.auto_now or (self.auto_now_add and add and
 getattr(model_instance, self.attname, None) is None):
  value = datetime.date.today()
  setattr(model_instance, self.attname, value)
  return value
 @@ -1424,7 +1424,7 @@ class DateTimeField(DateField):
  )

  def pre_save(self, model_instance, add):
 -if self.auto_now or (self.auto_now_add and add):
 +if self.auto_now or (self.auto_now_add and add and
 getattr(model_instance, self.attname, None) is None):
  value = timezone.now()
  setattr(model_instance, self.attname, value)
  return value
 @@ -2264,7 +2264,7 @@ class TimeField(DateTimeCheckMixin, Field):
  )

  def pre_save(self, model_instance, add):
 -if self.auto_now or (self.auto_now_add and add):
 +if self.auto_now or (self.auto_now_add and add and
 getattr(model_instance, self.attname, None) is None):
  value = datetime.datetime.now().time()
  setattr(model_instance, self.attname, value)
  return value
 diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
 --- a/docs/ref/models/fields.txt
 +++ b/docs/ref/models/fields.txt
 @@ -514,9 +514,8 @@ optional arguments:
  .. attribute:: DateField.auto_now_add

  Automatically set the field to now when the object is first created.
 Useful
 -for creation of timestamps. Note that the current date is *always*
 used;
 -it's not just a default value that you can override. So even if you
 -set a value for this field when creating the object, it will be
 ignored.
 +for creation of timestamps. If you set a value for this field when
 creating
 +the object, auto_now_add will be ignored.
  If you want to be able to modify this field, set the following
 instead of
  ``auto_now_add=True``:

 }}}

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

[Django] #28670: django/db/backends/oracle/compiler.py handling of LIMIT+OFFSET could be better in Oracle 12+.

2017-10-02 Thread Django

#28670: django/db/backends/oracle/compiler.py handling of LIMIT+OFFSET could be
better in Oracle 12+.
-+-
   Reporter:  Markus |  Owner:  nobody
  Stenberg   |
   Type: | Status:  new
  Cleanup/optimization   |
  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  |
-+-
 Currently the code which does the LIMIT+OFFSET clause emulation there with
 ROWNUM (which assorted sources on the internet recommend not to do) is no
 longer needed. Oracle 12 supports  SQL syntax for this:

 https://oracle-base.com/articles/12c/row-limiting-clause-for-top-n
 -queries-12cr1

 {{{
 [ OFFSET offset { ROW | ROWS } ]
 [ FETCH { FIRST | NEXT } [ { rowcount | percent PERCENT } ]
 { ROW | ROWS } { ONLY | WITH TIES } ]
 }}}

 This applies to all versions, but is probably reasonable to implement in
 2.0+ onlyas then there is no need to worry about Oracle 11 which does not
 support the syntax.

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

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-02 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 You could test `connection.ops.bulk_batch_size()` instead of testing by
 executing a query.

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

Re: [Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

2017-10-02 Thread Django

#28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) 
returns
False
-+-
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Old description:

> Expected: True
>
> In particular this shows up when trying to provide a custom
> ungettext_lazy message to django.core.BaseValidator (or any subclass).
>
> Not sure if this is also present on Django>1.8 (couldn't find any
> existing references to this bug).

New description:

 Expected: True

 In particular this shows up when trying to provide a custom ungettext_lazy
 message to django.core.BaseValidator (or any subclass), since message is
 only overriden in `__init__` `if message`

 Not sure if this is also present on Django>1.8 (couldn't find any existing
 references to this bug).

--

Comment (by Dylan Young):

 I'm happy to tackle this an approach is agreed upon.  It's totally
 possible that this is expected and simply requires 1) documentation and 2)
 better checks for overrides (i.e. `if message is not None`).  This would,
 however, probably be the most painful approach to fixing it as all `if
 message` and similar checks would need to be identified and audited.

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

Re: [Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

2017-10-02 Thread Django

#28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) 
returns
False
-+-
 Reporter:  Dylan Young  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Dylan Young:

Old description:

> Expected: True
>
> This does not seem to be an issue with the non-lazy version.
>
> In particular this shows up when trying to provide a custom
> ungettext_lazy message to django.core.BaseValidator (or any subclass).
>
> Not sure if this is also present on Django>1.8 (couldn't find any
> existing references to this bug).

New description:

 Expected: True

 In particular this shows up when trying to provide a custom ungettext_lazy
 message to django.core.BaseValidator (or any subclass).

 Not sure if this is also present on Django>1.8 (couldn't find any existing
 references to this bug).

--

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

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

[Django] #28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) returns False

2017-10-02 Thread Django

#28669: bool(ungettext_lazy('%(value)d blah', '%(value)d blahs', 'value')) 
returns
False
+
   Reporter:  Dylan Young   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Internationalization  |Version:  1.8
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Expected: True

 This does not seem to be an issue with the non-lazy version.

 In particular this shows up when trying to provide a custom ungettext_lazy
 message to django.core.BaseValidator (or any subclass).

 Not sure if this is also present on Django>1.8 (couldn't find any existing
 references to this bug).

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

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

Re: [Django] #28642: Add LRU caching to parse_accept_lang_header

2017-10-02 Thread Django

#28642: Add LRU caching to parse_accept_lang_header
--+
 Reporter:  Tom   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Internationalization  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f1c007bbf2fcd4996e29f0482c32faf5df397aa0" f1c007bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1c007bbf2fcd4996e29f0482c32faf5df397aa0"
 Fixed #28642 -- Added caching to parse_accept_lang_header().
 }}}

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

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

Re: [Django] #28596: Oracle crashes with query with 2^16+1 bind parameters.

2017-10-02 Thread Django

#28596: Oracle crashes with query with 2^16+1 bind parameters.
-+-
 Reporter:  Markus Stenberg  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * version:  1.11 => master


Comment:

 When I was working on this PR I encountered similar issue with
 `bulk_create()`. I prepared [https://github.com/django/django/pull/9178
 PR] with fix. Unfortunately test is not feasible, because it takes almost
 30 minutes and exceeds db memory limit: "''ORA-04036: PGA memory used by
 the instance exceeds PGA_AGGREGATE_LIMIT''".

 {{{#!python
 diff --git a/tests/bulk_create/tests.py b/tests/bulk_create/tests.py
 index 2439050623..0dd9549902 100644
 --- a/tests/bulk_create/tests.py
 +++ b/tests/bulk_create/tests.py
 @@ -255,3 +255,7 @@ class BulkCreateTests(TestCase):
  # Objects save via bulk_create() and save() should have equal
 state.
  self.assertEqual(country_nl._state.adding,
 country_be._state.adding)
  self.assertEqual(country_nl._state.db, country_be._state.db)
 +
 +def test_exceed_db_max_query_params(self):
 +# Oracle has limitation of number of parameters in a query.
 +Restaurant.objects.bulk_create((Restaurant(name='r'),) * 2**16)
 }}}

 Before this fix test failed with: "''ORA-00600: internal error code,
 arguments: [qcscbndv1], [65535], [], [], [], [], [], [], [], [], [],
 []''".

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

Re: [Django] #27804: Use unittest.subTest() in Django's test suite

2017-10-02 Thread Django

#27804: Use unittest.subTest() in Django's test suite
-+-
 Reporter:  Tim Graham   |Owner:  Marcin
 Type:   |  Baranowski
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f04e6732c33e0fd67e82ab2d59f230fa0045d15b" f04e6732]:
 {{{
 #!CommitTicketReference repository=""
 revision="f04e6732c33e0fd67e82ab2d59f230fa0045d15b"
 Refs #27804 -- Used subTest() in parse_accept_lang_header() test.
 }}}

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

Re: [Django] #28575: Model.DoesNotExist classes are not pickleable

2017-10-02 Thread Django

#28575: Model.DoesNotExist classes are not pickleable
-+-
 Reporter:  Rachel Tobin |Owner:  nobody
 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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #28595: Database "execute hooks" for instrumentation

2017-10-02 Thread Django

#28595: Database "execute hooks" for instrumentation
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 |  Berger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #28490: Descriptors on Models are reported as nonexistent by System Check Framework for ModelAdmin.list_display if they return None

2017-10-02 Thread Django

#28490: Descriptors on Models are reported as nonexistent by System Check 
Framework
for ModelAdmin.list_display if they return None
-+-
 Reporter:  Hunter Richards  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin, descriptor,   | Triage Stage:  Accepted
  system, checks, framework, |
  validation |
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
 * resolution:   => fixed


Comment:

 In [changeset:"47016adbf54b54143d4cf052eeb29fc72d27e6b1" 47016adb]:
 {{{
 #!CommitTicketReference repository=""
 revision="47016adbf54b54143d4cf052eeb29fc72d27e6b1"
 Fixed #28490 -- Removed unused code in admin.E108 check.
 }}}

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

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

2017-10-02 Thread Django

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

 * needs_better_patch:  0 => 1


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

Re: [Django] #28636: Translation module: Check `LANG_INFO` against user's language preference as optional feature

2017-10-02 Thread Django

#28636: Translation module: Check `LANG_INFO` against user's language 
preference as
optional feature
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 OK, I would suggest a slightly different approach. Could you have a look
 to this commit and tell me your opinion?
 https://github.com/django/django/compare/master...claudep:28636?expand=1

 The idea is to allow for custom fallback by subclassing the
 `LocaleMiddleware` and setting the `fallback_language` class variable
 (which would be `'en'` in your case).

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

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

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

2017-10-02 Thread Django

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom  |Owner:  Tom
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom):

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


Comment:

 If in the future we want to add support for `ON CONFLICT UPDATE` we should
 design the API with that in mind.

 Perhaps have `DO_NOTHING` as a sentinel object, so in the future we can
 pass in something else to describe updating (like a dictionary or
 somesuch?).

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

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

Re: [Django] #28652: Small fixes to some comments in django/db/models/query.py

2017-10-02 Thread Django

#28652: Small fixes to some comments in django/db/models/query.py
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 ):

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


Comment:

 In [changeset:"5d9b736fd8e09e273fb5aeeca0da268ecea5f1fd" 5d9b736]:
 {{{
 #!CommitTicketReference repository=""
 revision="5d9b736fd8e09e273fb5aeeca0da268ecea5f1fd"
 Fixed #28652 -- Fixed a few comments in django/db/models/*.
 }}}

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

Re: [Django] #28652: Small fixes to some comments in django/db/models/query.py

2017-10-02 Thread Django

#28652: Small fixes to some comments in django/db/models/query.py
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

 On maser not much has changed, apart from removing the docstring from
 sql/subquery.py:InsertQuery:insert_values
 {{{
 diff --git a/django/db/models/query.py b/django/db/models/query.py
 --- a/django/db/models/query.py
 +++ b/django/db/models/query.py
 @@ -232,7 +232,7 @@ class QuerySet:
 - Returns 100 rows at time
 (constants.GET_ITERATOR_CHUNK_SIZE)
   using cursor.fetchmany(). This part is responsible for
   doing some column masking, and returning the rows in
 chunks.
 -2. sql/compiler.results_iter()
 +2. sql.compiler.results_iter()
 - Returns one row at time. At this point the rows are
 still just
   tuples. In some cases the return values are converted to
   Python values at this location.
 @@ -402,7 +402,7 @@ class QuerySet:
  #insert into the childmost table.
  # We currently set the primary keys on the objects when using
  # PostgreSQL via the RETURNING ID clause. It should be possible
 for
 -# Oracle as well, but the semantics for  extracting the primary
 keys is
 +# Oracle as well, but the semantics for extracting the primary
 keys is
  # trickier so it's not done yet.
  assert batch_size is None or batch_size > 0
  # Check that the parents share the same concrete model with the
 our
 diff --git a/django/db/models/sql/compiler.py
 b/django/db/models/sql/compiler.py
 --- a/django/db/models/sql/compiler.py
 +++ b/django/db/models/sql/compiler.py
 @@ -889,8 +889,7 @@ class SQLCompiler:
  raise

  if result_type == CURSOR:
 -# Caller didn't specify a result_type, so just give them back
 the
 -# cursor to process (and close).
 +# Just give the caller back the cursor to process (and
 close).
  return cursor
  if result_type == SINGLE:
  try:
 }}}

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

Re: [Django] #28641: Improvements to QuerySet.bulk_create()

2017-10-02 Thread Django

#28641: Improvements to QuerySet.bulk_create()
-+-
 Reporter:  Дилян Палаузов   |Owner:  nobody
 Type:  New feature  |   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 Tim Graham):

 #28668 is created for ON CONFLICT DO NOTHING support.

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

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

2017-10-02 Thread Django

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:  New feature  |   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
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Old description:

> When using bulk_create it would be nice to support `ON CONFLICT DO
> NOTHING`, which allows existing rows to be included in the `bulk_create`
> call, e.g:
>
> {{{#!python
> Comment.objects.create(name='test', text='test')
> Comment.objects.bulk_create(Comment(name='test', text='test'),
> on_conflict=IGNORE)  # Does not throw an exception
> }}}
>
> All the databases we support have syntax for this, as well as
> updating/replacing fields.
>
> This is a spin-off of https://code.djangoproject.com/ticket/28641, just
> including the ON CONFLICT idea which is backwards-compatible and would be
> easier to implement than the others.

New description:

 When using bulk_create it would be nice to support `ON CONFLICT DO
 NOTHING`, which allows existing rows to be included in the `bulk_create`
 call, e.g:

 {{{#!python
 Comment.objects.create(name='test', text='test')
 Comment.objects.bulk_create(Comment(name='test', text='test'),
 on_conflict=IGNORE)  # Does not throw an exception
 }}}

 All the databases we support have syntax for this, as well as
 updating/replacing fields.

 This is a spin-off of #28641, just including the ON CONFLICT idea which is
 backwards-compatible and would be easier to implement than the others.

--

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

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

Re: [Django] #28613: Document that GenericForeignKey returns None when referring to nonexistent pk

2017-10-02 Thread Django

#28613: Document that GenericForeignKey returns None when referring to 
nonexistent
pk
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  Harshit
 Type:   |  Jain
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  genericforeignkey| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

Re: [Django] #28667: Documentation for extending UserCreationForm doesn't work with UserAdmin (was: Lack of clear documentation for custom UserCreationForm when using a custom User model)

2017-10-02 Thread Django

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

 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization


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

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

2017-10-02 Thread Django

#23919: Cleanups for when we drop Python 2 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"d896809a3ae8dfe45864f284c3ef45bfbb2e5ba1" d896809a]:
 {{{
 #!CommitTicketReference repository=""
 revision="d896809a3ae8dfe45864f284c3ef45bfbb2e5ba1"
 Refs #23919 -- Removed unneeded float()/int() calls.
 }}}

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

Re: [Django] #28613: Document that GenericForeignKey returns None when referring to nonexistent pk

2017-10-02 Thread Django

#28613: Document that GenericForeignKey returns None when referring to 
nonexistent
pk
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  Harshit
 Type:   |  Jain
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  genericforeignkey| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Harshit Jain):

 * has_patch:  0 => 1


Comment:

 The Documentation has been added. Here is the link to the pull request -
 [https://github.com/django/django/pull/9181].

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

Re: [Django] #28668: Add support for ON CONFLICT to bulk_create

2017-10-02 Thread Django

#28668: Add support for ON CONFLICT to bulk_create
-+-
 Reporter:  Tom  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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:

Old description:

> When using bulk_create it would be nice to support `ON CONFLICT DO
> NOTHING`, which allows existing rows to be included in the `bulk_create`
> call, e.g:
>
> {{{#!python
> Comment.objects.create(name='test', text='test')
> Comment.objects.bulk_create(Comment(name='test', text='test'),
> on_conflict=IGNORE)  # Does not throw an exception
> }}}
>
> All the databases we support have syntax for this, as well as
> updating/replacing fields.

New description:

 When using bulk_create it would be nice to support `ON CONFLICT DO
 NOTHING`, which allows existing rows to be included in the `bulk_create`
 call, e.g:

 {{{#!python
 Comment.objects.create(name='test', text='test')
 Comment.objects.bulk_create(Comment(name='test', text='test'),
 on_conflict=IGNORE)  # Does not throw an exception
 }}}

 All the databases we support have syntax for this, as well as
 updating/replacing fields.

 This is a spin-off of https://code.djangoproject.com/ticket/28641, just
 including the ON CONFLICT idea which is backwards-compatible and would be
 easier to implement than the others.

--

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

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

[Django] #28668: Add support for ON CONFLICT to bulk_create

2017-10-02 Thread Django

#28668: Add support for ON CONFLICT to bulk_create
-+-
   Reporter:  Tom|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using bulk_create it would be nice to support `ON CONFLICT DO
 NOTHING`, which allows existing rows to be included in the `bulk_create`
 call, e.g:

 {{{#!python
 Comment.objects.create(name='test', text='test')
 Comment.objects.bulk_create(Comment(name='test', text='test'),
 on_conflict=IGNORE)  # Does not throw an exception
 }}}

 All the databases we support have syntax for this, as well as
 updating/replacing fields.

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

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

Re: [Django] #28636: Translation module: Check `LANG_INFO` against user's language preference as optional feature

2017-10-02 Thread Django

Comment (by Denis Anuschewski):

No problem :-)
> Just one more question, wouldn't setting `LANGUAGE_CODE = 'en'` solve
your issue?
Actually that was the first thing I did. But no, it has one giant
drawback: because my language of original strings is German, setting
`LANGUAGE_CODE` to 'en' leads to the necessity of having to maintain
redundant German translations (or I get English translations for German
users). Additionally when changing the central `LANGUAGE_CODE` setting you
have to also change a lot of other stuff, e.g. in order for unit tests to
go through.

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

Re: [Django] #28663: Check for incorrectly migrated django.urls.path calls

2017-10-02 Thread Django

#28663: Check for incorrectly migrated django.urls.path calls
-+--
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (URLs)  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  check urls   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Chris Lamb):

 PR updated after review.

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

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

Re: [Django] #28636: Translation module: Check `LANG_INFO` against user's language preference as optional feature

2017-10-02 Thread Django

#28636: Translation module: Check `LANG_INFO` against user's language 
preference as
optional feature
-+-
 Reporter:  Denis Anuschewski|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I also appreciate your patience while explaining your use case to me :-)

 Just one more question, wouldn't setting `LANGUAGE_CODE = 'en'` solve your
 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/066.a852b1295a8c08089ed8da2baf7d76e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

38 matches

Mail list logo