date:20190415

Re: [Django] #10070: Named parameters not working on raw sql queries with sqlite

2019-04-15 Thread Django

#10070: Named parameters not working on raw sql queries with sqlite
-+-
 Reporter:  Matias Surdi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shai Berger):

 Replying to [comment:16 Tobias Kunze]:
 > This syntax isn't documented (as far as I can see, at least not in
 `topics/db/sql`) – do we want to add documentation for this, and exclude
 SQLite?

 That much I did almost six years ago, as noted in comment:14 -- and it is
 still [https://docs.djangoproject.com/en/2.2/topics/db/sql/#passing-
 parameters-into-raw there].

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

Re: [Django] #10070: Named parameters not working on raw sql queries with sqlite

2019-04-15 Thread Django

#10070: Named parameters not working on raw sql queries with sqlite
-+-
 Reporter:  Matias Surdi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

 * version:  1.0 => master


Comment:

 This still breaks on SQLite (3.27.2), although with a less helpful error
 message:


 {{{
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 67, in execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers
 return executor(sql, params, many, context)
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/utils.py", line 89, in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/backends/utils.py", line 84, in _execute
 return self.cursor.execute(sql, params)
   File "/home/rixx/.local/share/virtualenvs/demo/lib/python3.7/site-
 packages/django/db/backends/sqlite3/base.py", line 383, in execute
 return Database.Cursor.execute(self, query, params)
 django.db.utils.OperationalError: near "%": syntax error
 }}}

 This syntax isn't documented (as far as I can see, at least not in
 `topics/db/sql`) – do we want to add documentation for this, and exclude
 SQLite?

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

Re: [Django] #29338: Can't use OuterRef in union Subquery

2019-04-15 Thread Django

#29338: Can't use OuterRef in union Subquery
-+-
 Reporter:  Matthew Pava |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (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 Tobias Kunze):

 * status:  new => assigned
 * owner:  nobody => Can Sarıgöl


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

Re: [Django] #30310: New HTTPRequest.headers not usable in templates because of hyphens

2019-04-15 Thread Django

#30310: New HTTPRequest.headers not usable in templates because of hyphens
-+-
 Reporter:  Mark Tranchant   |Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  request headers  | Triage Stage:  Ready for
  hyphen template|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

 * owner:  nobody => Nick Pope
 * status:  new => assigned
 * needs_tests:  1 => 0
 * 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/071.f5e2a702588b367a3fcc966fbd0233b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30335: TypeError: unhashable type: 'list' when paginating queryset with KeyTransform annotation

2019-04-15 Thread Django

#30335: TypeError: unhashable type: 'list' when paginating queryset with
KeyTransform annotation
-+-
 Reporter:  Jaap Roes|Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgresql jsonb | Triage Stage:  Accepted
  keytransform annotation|
  pagination |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

 * status:  new => assigned
 * owner:  nobody => Can Sarıgöl


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

Re: [Django] #30196: Make FileResponse always set Content-Disposition header.

2019-04-15 Thread Django

#30196: Make FileResponse always set Content-Disposition header.
-+-
 Reporter:  Piotr Kunicki|Owner:  Piotr
 Type:   |  Kunicki
  Cleanup/optimization   |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  FileResponse file| Triage Stage:  Ready for
  response Content-Disposition   |  checkin
  header attachment inline   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

Re: [Django] #30339: Model.delete(keep_parents=True) does not preserve all parent reverse relationships

2019-04-15 Thread Django

#30339: Model.delete(keep_parents=True) does not preserve all parent reverse
relationships
-+-
 Reporter:  Stephen Brown|Owner:  Stephen
 |  Brown
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models deletion  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

 * status:  new => assigned
 * owner:  nobody => Stephen Brown


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

Re: [Django] #14688: BaseInlineFormSet does not support "auto_id"

2019-04-15 Thread Django

#14688: BaseInlineFormSet does not support "auto_id"
---+
 Reporter:  Victor Andrée  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 Keywords:  formsets   | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tobias Kunze):

 * status:  new => closed
 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * resolution:   => fixed
 * needs_tests:  1 => 0


Comment:

 This issue has been fixed some time ago: In e308cfc0e15 (7 years ago, a
 year after this issue was opened), `BaseInlineFormSet` started passing
 `**kwargs` in its `super()` call.

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

Re: [Django] #30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`

2019-04-15 Thread Django

#30367: Docs: Change examples using bare `pip ...` to `python -m pip ...`
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 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 Tobias Kunze):

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


Comment:

 I think this makes sense. It's a bit more verbose, but removes a source of
 errors that are particularly hard to debug for beginners.

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

Re: [Django] #30365: Sphinx interprets some "%[a-z]" in SQL statements as "Literal.String.Interpol" which breaks highlighting.

2019-04-15 Thread Django

#30365: Sphinx interprets some "%[a-z]" in SQL statements as
"Literal.String.Interpol" which breaks highlighting.
-+-
 Reporter:  Daniel Musketa   |Owner:  Daniel
 Type:   |  Musketa
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-15 Thread Django

#30361: Watchman timing out when loading server
---+
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 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 Tobias Kunze):

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

Re: [Django] #14831: Django Template Style Guide

2019-04-15 Thread Django

* cc: Tobias Kunze (added)

Comment:

By now, there is a
[https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
/coding-style/#template-style place] to add further template style guides
(currently it only says to add one space between `{{` and the variable
name. So we'd need a consensus on what a good template style would mean:
Indented for template readability or for meaningful HTML indentation?
Indented by two spaces or four?

I'd be all for two spaces and indentation as proposed by
[https://code.djangoproject.com/ticket/14831#comment:4 Simon].

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

Re: [Django] #14808: i18n is not safe.

2019-04-15 Thread Django

#14808: i18n is not safe.
---+
 Reporter:  Stephen Kelly  |Owner:  Tobias Kunze
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by felixxm):

 * version:  1.2 => master


Comment:

 [https://github.com/django/django/pull/11236 PR]

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

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

Re: [Django] #14009: custom formset validation documentation is incomplete

2019-04-15 Thread Django

#14009: custom formset validation documentation is incomplete
-+-
 Reporter:  splatEric|Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset validation   | 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):

 * version:  1.2 => master


Comment:

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

Re: [Django] #14808: i18n is not safe.

2019-04-15 Thread Django

#14808: i18n is not safe.
---+
 Reporter:  Stephen Kelly  |Owner:  Tobias Kunze
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.2
 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 Tobias Kunze):

 * owner:  nobody => Tobias Kunze
 * status:  new => assigned
 * has_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/066.edcd22ad9ca70f4170622655d894792c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

2019-04-15 Thread Django

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated
as
a proxy.
-+--
Reporter: Julien Enselme |Owner: Arthur Rio
Type: Bug | Status: assigned
Component: contrib.auth | Version: 2.2
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+--
Changes (by Arthur Rio):

* owner: nobody => Arthur Rio
* status: new => assigned

Comment:

We do not automatically delete stale content types on purpose to avoid
data loss. When deleting a model, the `remove_stale_contenttypes.py`
management command

[https://github.com/django/django/blob/master/django/contrib/contenttypes/management/commands/remove_stale_contenttypes.py]
should be ran. We can do two things here:
1. Handle the `IntegrityError` with a helpful message to point to the
command
2. Re-use existing content types

I think 1. is safer but I am open to suggestions.

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

Re: [Django] #13677: ModelFormSet may query wrong database backend

2019-04-15 Thread Django

#13677: ModelFormSet may query wrong database backend
--+
 Reporter:  Pierre Chifflier  |Owner:  Tobias Kunze
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.2
 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 Tobias Kunze):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #14009: custom formset validation documentation is incomplete

2019-04-15 Thread Django

#14009: custom formset validation documentation is incomplete
-+-
 Reporter:  splatEric|Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  formset validation   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-15 Thread Django

#30361: Watchman timing out when loading server
---+--
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 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 Tobias Kunze):

 A more generous default timeout might be a better choice than a
 configuration option, in my opinion. In any case it would be great if
 somebody who runs into this consistently could test
 [https://github.com/rixx/django/commit/ec873d1448ebe922502c517c8ef90f441f1813ab
 my patch] or provide one of their own.

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

Re: [Django] #14009: custom formset validation documentation is incomplete

2019-04-15 Thread Django

#14009: custom formset validation documentation is incomplete
-+-
 Reporter:  splatEric|Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  formset validation   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tobias Kunze):

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-15 Thread Django

#30361: Watchman timing out when loading server
---+--
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 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 Peter J. Farrell):

 We are seeing the same issue especially the container starts (less often
 if it's just a server reload). It appears the timeout on pywatchman needs
 to be configurable from Django in this case as 1.0 seconds is too low in
 certain circumstances.

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Ticket #30325 revealed one more issue, i.e. optimization doesn't work when
 chaining `all()` after reverse M2M relations.

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 Switched back to ''patch needs improvement'' instead as it can probably be
 adapted to skip the optimization when a custom manager is defined.

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

Re: [Django] #30368: Prefetch related is not working when used GFK for model that uses FK as PK. (was: prefetch_related does not work for GenericForeignKey field when its primary key is also a foreign

2019-04-15 Thread Django

#30368: Prefetch related is not working when used GFK for model that uses FK as 
PK.
-+-
 Reporter:  Vinny Do |Owner:  Vinny Do
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
  genericforeignkey  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => assigned
 * owner:  nobody => Vinny Do
 * stage:  Unreviewed => Accepted


Comment:

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

[Django] #30371: sqlmigrate fails with string defaults on mysql

2019-04-15 Thread Django

#30371: sqlmigrate fails with string defaults on mysql
-+-
   Reporter:  Melvyn |  Owner:  nobody
  Sopacua|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  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 we have a migration that is adding strings defaults to a field,
 sqlmigrate will fail:

 {{{
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/migrations/migration.py", line 124, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/migrations/operations/fields.py", line 84, in
 database_forwards
 field,
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/backends/mysql/schema.py", line 42, in add_field
 super().add_field(model, field)
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/backends/base/schema.py", line 435, in add_field
 self.execute(sql, params)
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/backends/base/schema.py", line 128, in execute
 self.collected_sql.append((sql % tuple(map(self.quote_value, params)))
 + ending)
   File "/home/melvyn/.local/py-env/button3d-7LYQbQGk/lib/python3.6/site-
 packages/django/db/backends/mysql/schema.py", line 31, in quote_value
 quoted = quoted.decode()
 AttributeError: 'str' object has no attribute 'decode'
 }}}

 This is because of the quote_value method calling `decode()` on a string
 object (it is a method of a byte object). This doesn't happen when the
 migration is being applied, presumably, because then we're creating byte
 objects and the code doesn't trigger, but this is a guess.

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 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):

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

Re: [Django] #30296: Add how-to guide for JavaScript frameworks integration

2019-04-15 Thread Django

#30296: Add how-to guide for JavaScript frameworks integration
-+-
 Reporter:  Maciej Olko  |Owner:  Josef
 |  Rousek
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  javascript, rest,| Triage Stage:  Accepted
  api, assets|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josef Rousek):

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2019-04-15 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  Richard Howard   |Owner:  Piotr
 |  Pawlaczek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bump_prefix  | Triage Stage:  Ready for
  subquery alias |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0cb40624828f3590ea2460e2e0cf1bd5a2b52496" 0cb4062]:
 {{{
 #!CommitTicketReference repository=""
 revision="0cb40624828f3590ea2460e2e0cf1bd5a2b52496"
 Refs #23758 -- Used RecursionError instead of RuntimeError to raise nested
 subquery errors.

 RecursionError was introduced in Python 3.5 and subclasses RuntimeError.
 }}}

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

Re: [Django] #27149: Allow using a subquery in QuerySet.filter()

2019-04-15 Thread Django

#27149: Allow using a subquery in QuerySet.filter()
-+-
 Reporter:  MikiSoft |Owner:  Matthew
 |  Schinckel
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Queryset SubQuery| Triage Stage:  Ready for
  Exists |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c0969ee22741f15841a55b4420c113a9eac1c7a5" c0969ee]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0969ee22741f15841a55b4420c113a9eac1c7a5"
 Refs #27149 -- Based recursive nested subquery detection on
 sys.getrecursionlimit().

 This makes sure the test_avoid_infinite_loop_on_too_many_subqueries test
 doesn't fail on systems with a non-default recursion limit.
 }}}

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

Re: [Django] #30333: hash is not inherited from model.Model if eq is defined

2019-04-15 Thread Django

#30333: __hash__  is not inherited from model.Model if __eq__ is defined
-+-
 Reporter:  Adam Janik   |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 Carlton Gibson):

 * status:  assigned => closed
 * resolution:   => duplicate
 * severity:  Release blocker => Normal


Comment:

 Ultimately this is a slightly different version of #30254, which was
 raised after a68ea231012434b522ce45c513d84add516afa60.
 (Will resolve as a duplicate.)

 Prior to the changes in a68ea231012434b522ce45c513d84add516afa60 the model
 would
 inherit **both** `__eq__()` and `__hash__()` from `models.Model` during
 `__new__()`.
 (With `__eq__()` then being replaced in the `add_to_class()` call later.)

 This was incorrect. The Python docs are quite specific:

 > A class that overrides __eq__() and does not define __hash__() will have
 its __hash__() implicitly set to None. When the __hash__() method of a
 class is None, instances of the class will raise an appropriate TypeError
 when a program attempts to retrieve their hash value, and will also be
 correctly identified as unhashable when checking isinstance(obj,
 collections.abc.Hashable).
 >
 > If a class that overrides __eq__() needs to retain the implementation of
 __hash__() from a parent class, the interpreter must be told this
 explicitly by setting __hash__ = .__hash__.

 By passing the defined `__eq__()` (as well as `__hash__()` if defined)
 into `__new__()`, the change is bringing Django's behaviour into line with
 Python's.

 The changes here were a bug fix, rather than a breaking change per se.
 (Yes, it **is** a
 change in behaviour, but so are all bugfixes, and we don't list them as
 breaking changes in the release notes.)

 I've [https://github.com/django/django/pull/11184 added a couple test
 cases demonstrating the expected behaviour in a PR]. In particular the
 `test_missing_hash_not_inherited()` cases fails on Django 2.1.

 The fix for your project is to explicitly declare the `__hash__ `
 attribute as per the docs above:


 {{{
 __hash__ = models.Model.__hash__
 }}}

 I hope that helps.

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

Re: [Django] #30348: Add superuser_required decorator

2019-04-15 Thread Django

#30348: Add superuser_required decorator
--+--
 Reporter:  Sultan Iman   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Sultan Iman):

 Replying to [comment:1 Tobias Kunze]:
 > Summing up the discussion on the GitHub PR here:
 >
 > On the plus side, Django does provide very similar decorators and
 mixins, so it is surprising that `superuser_required` is not already a
 part of Django.
 >
 > On the other hand, adding a decorator like this is trivial with
 `user_passes_test`. We could add a decorator like this to the
 ``user_passes_test`` documentation, to make sure searching for this
 (fairly reasonable) requirement yields helpful information.

 Hi Tobias,

 Thanks for reviewing! Also agree that it is easily achievable. However I
 believe providing these out of the box is a good developer experience as
 well as convenience.



 ---
 Kind regards,
 Sultan.

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

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

Re: [Django] #30348: Add superuser_required decorator

2019-04-15 Thread Django

#30348: Add superuser_required decorator
--+--
 Reporter:  Sultan Iman   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Sultan Iman:

Old description:

> Create a new decorator **superuser_required** which has use cases when
> only super users can access certain views.
> Github PR is at https://github.com/django/django/pull/10640

New description:

 Create a new decorator **superuser_required** and
 **SuperuserRequiredMixin** which has use cases when only super users can
 access certain views.
 Github PR is at https://github.com/django/django/pull/10640

--

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

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  new
  Cleanup/optimization   |
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):

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


Comment:

 Solution has been reverted because it caused the inconsistent behavior of
 `count()` and `exists()` on a reverse many-to-many relationship with a
 custom manager (see new tests in
 9ac8520fcde29840a1345be19d80dbda53aa6d03).

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-15 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e8de1cc94c9a251ba7c569468f1e94faf9a05671" e8de1cc9]:
 {{{
 #!CommitTicketReference repository=""
 revision="e8de1cc94c9a251ba7c569468f1e94faf9a05671"
 [2.2.x] Fixed #30325 -- Reverted "Fixed #29725 -- Removed unnecessary join
 in QuerySet.count() and exists() on a many-to-many relation."

 This reverts commit 1299421cadc4fcf63585f2f88337078e43e660e0 due to
 a regression with custom managers.

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-15 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"5289d4faec5ddc7592c719825914fe430003f724" 5289d4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="5289d4faec5ddc7592c719825914fe430003f724"
 [2.2.x] Refs #30325 -- Added tests for using count()/exists() with custom
 managers and reverse M2M relations.

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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 Mariusz Felisiak ):

 In [changeset:"e8de1cc94c9a251ba7c569468f1e94faf9a05671" e8de1cc9]:
 {{{
 #!CommitTicketReference repository=""
 revision="e8de1cc94c9a251ba7c569468f1e94faf9a05671"
 [2.2.x] Fixed #30325 -- Reverted "Fixed #29725 -- Removed unnecessary join
 in QuerySet.count() and exists() on a many-to-many relation."

 This reverts commit 1299421cadc4fcf63585f2f88337078e43e660e0 due to
 a regression with custom managers.

 Backport of 5f7991c42cff73b6278106d499d719b726f85ead from master
 }}}

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

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2019-04-15 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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 Mariusz Felisiak ):

 In [changeset:"5f7991c42cff73b6278106d499d719b726f85ead" 5f7991c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f7991c42cff73b6278106d499d719b726f85ead"
 Fixed #30325 -- Reverted "Fixed #29725 -- Removed unnecessary join in
 QuerySet.count() and exists() on a many-to-many relation."

 This reverts commit 1299421cadc4fcf63585f2f88337078e43e660e0 due to
 a regression with custom managers.
 }}}

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-15 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"5f7991c42cff73b6278106d499d719b726f85ead" 5f7991c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f7991c42cff73b6278106d499d719b726f85ead"
 Fixed #30325 -- Reverted "Fixed #29725 -- Removed unnecessary join in
 QuerySet.count() and exists() on a many-to-many relation."

 This reverts commit 1299421cadc4fcf63585f2f88337078e43e660e0 due to
 a regression with custom managers.
 }}}

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-15 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9ac8520fcde29840a1345be19d80dbda53aa6d03" 9ac8520]:
 {{{
 #!CommitTicketReference repository=""
 revision="9ac8520fcde29840a1345be19d80dbda53aa6d03"
 Refs #30325 -- Added tests for using count()/exists() with custom managers
 and reverse M2M relations.
 }}}

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

Re: [Django] #30365: Sphinx interprets some "%[a-z]" in SQL statements as "Literal.String.Interpol" which breaks highlighting. (was: Sphinx interprets some "%[a-z]" in SQL statements as "Literal.Strin

2019-04-15 Thread Django

#30365: Sphinx interprets some "%[a-z]" in SQL statements as
"Literal.String.Interpol" which breaks highlighting.
--+
 Reporter:  Daniel Musketa|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  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/061.320c5256c41fdd6dfcaf9d0d4db7cc97%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30365: Sphinx interprets some "%[a-z]" in SQL statements as "Literal.String.Interpol" which leads to weird highlighting. (was: Sphinx interprets some "%[a-z]" in SQL statements as "Liter

2019-04-15 Thread Django

#30365: Sphinx interprets some "%[a-z]" in SQL statements as
"Literal.String.Interpol" which leads to weird highlighting.
--+
 Reporter:  Daniel Musketa|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by felixxm):

 * version:  2.2 => master
 * easy:  0 => 1
 * 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/061.eb95e6be572f21929e994b3053169a08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy. (was: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to apply)

2019-04-15 Thread Django

#30351: Migration auth.0011_update_proxy_permissions fails for models recreated 
as
a proxy.
-+
 Reporter:  Julien Enselme   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Description changed by felixxm:

Old description:

> I am trying to update my project to Django 2.2. When I launch `python
> manage.py migrate`, I get this error message when migration
> `auth.0011_update_proxy_permissions` is applying (full stacktrace is
> available [https://dpaste.de/5nJJ here]):
> `django.db.utils.IntegrityError: duplicate key value violates unique
> constraint "idx_18141_auth_permission_content_type_id_01ab375a_uniq"
> DETAIL:  Key (content_type_id, codename)=(12, add_agency) already
> exists`.
>
> It looks like the migration is trying to re-create already existing
> entries in the `auth_permission` table. At first I though it cloud
> because we recently renamed a model. But after digging and deleting the
> entries associated with the renamed model from our database in the
> `auth_permission` table, the problem still occurs with other proxy
> models.
>
> I tried to update directly from 2.0.13 and 2.1.8. The issues appeared
> each time. I also deleted my venv and recreated it without an effect.
>
> I searched for a ticket about this on the bug tracker but found nothing.
> I also posted this on [https://groups.google.com/forum/#!topic/django-
> users/KPnsJCgw8-U django-users] and was asked to report this here.

New description:

 I am trying to update my project to Django 2.2. When I launch `python
 manage.py migrate`, I get this error message when migration
 `auth.0011_update_proxy_permissions` is applying (full stacktrace is
 available [https://dpaste.de/5nJJ here]):
 `django.db.utils.IntegrityError: duplicate key value violates unique
 constraint "idx_18141_auth_permission_content_type_id_01ab375a_uniq"
 DETAIL:  Key (co.ntent_type_id, codename)=(12, add_agency) already
 exists`.

 It looks like the migration is trying to re-create already existing
 entries in the `auth_permission` table. At first I though it cloud because
 we recently renamed a model. But after digging and deleting the entries
 associated with the renamed model from our database in the
 `auth_permission` table, the problem still occurs with other proxy models.

 I tried to update directly from 2.0.13 and 2.1.8. The issues appeared each
 time. I also deleted my venv and recreated it without an effect.

 I searched for a ticket about this on the bug tracker but found nothing. I
 also posted this on [https://groups.google.com/forum/#!topic/django-
 users/KPnsJCgw8-U django-users] and was asked to report this 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/066.df144d0e41627ded62f057694f899439%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to apply

2019-04-15 Thread Django

#30351: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to 
apply
-+
 Reporter:  Julien Enselme   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  2.2
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by felixxm):

 * cc: Simon Charette, Arthur Rio, Antoine Catton (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Reproduced with steps from
 [https://code.djangoproject.com/ticket/30351#comment:3 comment]. It's
 probably regression in 181fb60159e54d442d3610f4afba6f066a6dac05.

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

Re: [Django] #30370: Add support for postgresql client certificates and key to dbshell

2019-04-15 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell
-+-
 Reporter:  Oleh Mykytyuk|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dbshell postgresql   | Triage Stage:
  certificate|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Oleh Mykytyuk):

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

Re: [Django] #30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields with custom model manager

2019-04-15 Thread Django

#30325: Inconsistent count() behaviour on reverse relations in ManyToManyFields
with custom model manager
-+-
 Reporter:  Tobias Kunze |Owner:  Tobias
 |  Kunze
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

 * owner:  nobody => Tobias Kunze
 * status:  new => assigned
 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

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

[Django] #30370: Add support for postgresql client certificates and key to dbshell

2019-04-15 Thread Django

#30370: Add support for postgresql client certificates and key to dbshell
-+-
   Reporter:  oleh-  |  Owner:  nobody
  mykytyuk   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  dbshell postgresql
   Severity:  Normal |  certificate
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This bug is very similar to the #28322

 A common security procedure for DB access is to require mutual TLS for the
 DB connection.
 This involves specifying a server certificate, client certificate, and
 client key when connecting.
 Django already supports this configuration, it looks like this:

 {{{
 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.postgresql',
 'NAME': os.environ.get('POSTGRES_DB_NAME'),
 'USER': os.environ.get('POSTGRES_DB_USER'),
 'HOST': 'postgres',
 'PORT': '5432',
 'SCHEMA': os.environ.get('POSTGRES_DB_SCHEMA'),
 'OPTIONS': {
'sslmode': 'verify-ca',
'sslrootcert': os.environ.get('POSTGRES_CLI_SSL_CA',
 'ca.crt'),
'sslcert': os.environ.get('POSTGRES_CLI_SSL_CRT',
 'client_cert_chain.crt'),
'sslkey':  os.environ.get('POSTGRES_CLI_SSL_KEY',
 'client_key.key')
 }
 }
 }
 }}}

 However the dbshell command does not support the client cert params.
 Should be a trivial fix to add in support for the other 'ssl' parameters
 required 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/056.cbb4c49276b4e1a5fc7f6f3ff86e282c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30351: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to apply

2019-04-15 Thread Django

Comment (by Sébastiaan Versteeg):

To get into the situation where you already have permissions with the
content type you should be able to do the following:
- Start on Django <2.2
- Create a model called 'TestModel'
- Migrate
- Delete the model called 'TestModel'
- Add a new **proxy** model called 'TestModel'
- Migrate
- Update to Django >=2.2
- Migrate

We think this is what happened in our case where we found this issue
(https://sentry.thalia.nu/share/issue/68be0f8c32764dec97855b3cbb3d8b55/).
We have a proxy model with the same name that a previous non-proxy model
once had. This changed during a refactor and the permissions for the
original model still exist.
Our solution will probably be removing the existing permissions from the
table, but that's really only a workaround.

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

Re: [Django] #30361: Watchman timing out when loading server

2019-04-15 Thread Django

#30361: Watchman timing out when loading server
---+--
 Reporter:  Jacob Green|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  2.2
 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 Tobias Kunze):

 * cc: Tobias Kunze (added)


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

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

[Django] #30369: Creating database tables from queries based on ORM API

2019-04-15 Thread Django

#30369: Creating database tables from queries based on ORM API
-+-
   Reporter:  elfring|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  database tables,
   Severity:  Normal |  queries, ORM, API, SQL, storage
 |  management, object-relational
   Triage Stage: |  mapping, computation results, CTAS
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Value combinations can be counted in records also together with the
 software “Django 2.2” by
 [https://docs.djangoproject.com/en/2.2/ref/databases/ database services].
 I am looking for ways to store a computation result into a dynamically
 generated table.
 * How should such table creation be achieved by the programming interface
 “object-relational mapping”?
 * Would you like to support
 [https://en.wikipedia.org/wiki/Data_definition_language#CREATE_TABLE_statement
 the SQL command “CREATE TABLE AS SELECT” (CTAS)]?

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

Re: [Django] #27910: Allow using an Enum class in model Field choices

2019-04-15 Thread Django

#27910: Allow using an Enum class in model Field choices
-+-
 Reporter:  Marcel Hellwig   |Owner:  Shai
 |  Berger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  enum model choices   | 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


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

Re: [Django] #29607: Add doc examples of handling files and their lifecycles with FileField/models. (was: Add doc examples of handling files and their lifecycles with FileField/models)

2019-04-15 Thread Django

#29607: Add doc examples of handling files and their lifecycles with
FileField/models.
-+-
 Reporter:  Thomas Grainger  |Owner:  Chris
 Type:   |  Adams
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 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 felixxm):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * version:  2.0 => master


Comment:

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

Re: [Django] #30326: Document how to avoid F() assignments persistence

2019-04-15 Thread Django

#30326: Document how to avoid F() assignments persistence
-+-
 Reporter:  sage |Owner:  sage
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation,   | Triage Stage:  Ready for
  models, expressions|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"86de106864508872a3f5f1f24b2ceae4c6a3770f" 86de1068]:
 {{{
 #!CommitTicketReference repository=""
 revision="86de106864508872a3f5f1f24b2ceae4c6a3770f"
 [2.2.x] Fixed #30326 -- Doc'd how to avoid persistence of F() assignment.

 Backport of bfae195b0a2c8dae755610a7e23add5c6bc37b5e from master
 }}}

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

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

Re: [Django] #30326: Document how to avoid F() assignments persistence

2019-04-15 Thread Django

#30326: Document how to avoid F() assignments persistence
-+-
 Reporter:  sage |Owner:  sage
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  documentation,   | Triage Stage:  Ready for
  models, expressions|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"bfae195b0a2c8dae755610a7e23add5c6bc37b5e" bfae195b]:
 {{{
 #!CommitTicketReference repository=""
 revision="bfae195b0a2c8dae755610a7e23add5c6bc37b5e"
 Fixed #30326 -- Doc'd how to avoid persistence of F() assignment.
 }}}

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

Re: [Django] #30360: Support rotation of secret keys. (was: Support rotation of secret keys)

2019-04-15 Thread Django

#30360: Support rotation of secret keys.
---+-
 Reporter:  Andreas Pelme  |Owner:  Andreas Pelme
 Type:  New feature|   Status:  assigned
Component:  Core (Other)   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by felixxm):

 * type:  Uncategorized => New feature
 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Comment:

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

Re: [Django] #30368: prefetch_related does not work for GenericForeignKey field when its primary key is also a foreign key

2019-04-15 Thread Django

#30368: prefetch_related does not work for GenericForeignKey field when its 
primary
key is also a foreign key
-+-
 Reporter:  Vinny Do |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:
  genericforeignkey  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vinny Do):

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

[Django] #30368: prefetch_related does not work for GenericForeignKey field when its primary key is also a foreign key

2019-04-15 Thread Django

#30368: prefetch_related does not work for GenericForeignKey field when its 
primary
key is also a foreign key
-+-
   Reporter:  Vinny Do   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|   Keywords:  prefetch_related
   Severity:  Normal |  genericforeignkey
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 **Steps to reproduce**

 Create `Base` model with an `AutoField` primary key
 {{{#!python
 class Base(models.Model):
 title = models.TextField()
 }}}

 Create a model where the primary key is also a foreign key
 {{{#!python
 class Extended(models.Model):
 base = models.OneToOneField(Base, on_delete=models.CASCADE,
 primary_key=True)
 }}}

 Create model with `GenericForeignKey`
 {{{#!python
 class Comment(models.Model):
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE)
 object_pk = models.TextField()
 content_object = GenericForeignKey(ct_field="content_type",
 fk_field="object_pk")
 }}}

 Prefetch the GenericForeignKey field `content_object` expecting it to have
 a value but get `None` instead.
 {{{#!python
 # Setup
 base = Base.objects.create(title="foo")
 extended = Extended.objects.create(base=base)
 Comment.objects.create(content_object=extended)

 # Exercise
 comment = Comment.objects.prefetch_related("content_object").get()
 print(comment.content_object)
 }}}

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

56 matches

Mail list logo