date:20160920

Re: [Django] #27256: Change the selected attribute of select form tags to use HTML5 boolean syntax

2016-09-20 Thread Django

#27256: Change the selected attribute of select form tags to use HTML5 boolean
syntax
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

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

[Django] #27256: Change the selected attribute of select form tags to use HTML5 boolean syntax

2016-09-20 Thread Django

#27256: Change the selected attribute of select form tags to use HTML5 boolean
syntax
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Forms |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Similar to #26928

 Change the `selected` attribute of `select` form tags to use HTML5 boolean
 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/052.4602bafd48804bddbf34ebaecaeb78e3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27025: Python 3.6 compatibility

2016-09-20 Thread Django

Comment (by Tim Graham):

I setup a more complete test environment that includes all of the test
suite dependencies and identified a few more failures fixed in the above
commits.

2 failures remain as of Django b5aac66b28c615b2bda63548cbd695dbb5a0c381
and cpython

[https://github.com/python/cpython/commit/d614d687d9db1100d0a4ec8c67e0cb3ce773342b
d614d687d9db1100d0a4ec8c67e0cb3ce773342b] due to a sqlparse
incompatibility with Python 3.6. I submitted a
[https://github.com/andialbrecht/sqlparse/pull/292 PR] to fix it and it's
merged awaiting the next release.

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-09-20 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+-
 Reporter:  Matt Johnson  |Owner:  Andrew Konoff
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:  auth 1.11 | 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):

 * keywords:  auth => auth 1.11
 * has_patch:  1 => 0
 * type:  Bug => New feature
 * stage:  Ready for checkin => Accepted


Comment:

 It's appropriate to reopen a ticket if the fix hasn't been released yet.

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-09-20 Thread Django

#26401: Allow auth machinery to be used without installing auth app
-+-
 Reporter:  Matt Johnson |Owner:  Andrew
 |  Konoff
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  auth | 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 Jon Dufresne):

 * Attachment "ticket-26401-remove-stale-contenttypes.patch" added.

 Test case for remove_stale_contenttypes with auth migrations disabled

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-09-20 Thread Django

#26401: Allow auth machinery to be used without installing auth app
-+-
 Reporter:  Matt Johnson |Owner:  Andrew
 |  Konoff
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  auth | 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 Jon Dufresne):

 I've hit another snag with the `MIGRATION_MODULES = {'auth': None}`
 approach. (Sorry, is it better to reopen this ticket or file a new one?)

 The `auth.Permission` model has a fk on `ContentType`. Due to this, when
 deleting a `ContentType` (such as with the `remove_stale_contenttypes`
 command) queries against the missing `auth_permission` table can occur.

 Not sure how best to handle this scenario. IIUC, as long as auth is in
 `INSTALLED_APPS`, the models will be loaded and this FK will cause an
 issue.

 Here is a stack trace when deleting a stale content type

 {{{
 Traceback (most recent call last):
   File "/usr/lib64/python3.5/runpy.py", line 170, in _run_module_as_main
 "__main__", mod_spec)
   File "/usr/lib64/python3.5/runpy.py", line 85, in _run_code
 exec(code, run_globals)
   File "/home/jon/devel/django/django/__main__.py", line 9, in 
 management.execute_from_command_line()
   File "/home/jon/devel/django/django/core/management/__init__.py", line
 366, in execute_from_command_line
 utility.execute()
   File "/home/jon/devel/django/django/core/management/__init__.py", line
 358, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/jon/devel/django/django/core/management/base.py", line 294,
 in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/jon/devel/django/django/core/management/base.py", line 345,
 in execute
 output = self.handle(*args, **options)
   File
 
"/home/jon/devel/django/django/contrib/contenttypes/management/commands/remove_stale_contenttypes.py",
 line 46, in handle
 collector.collect([ct])
   File "/home/jon/devel/django/django/db/models/deletion.py", line 218, in
 collect
 elif sub_objs:
   File "/home/jon/devel/django/django/db/models/query.py", line 260, in
 __bool__
 self._fetch_all()
   File "/home/jon/devel/django/django/db/models/query.py", line 1072, in
 _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/jon/devel/django/django/db/models/query.py", line 54, in
 __iter__
 results = compiler.execute_sql()
   File "/home/jon/devel/django/django/db/models/sql/compiler.py", line
 847, in execute_sql
 cursor.execute(sql, params)
   File "/home/jon/devel/django/django/db/backends/utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
   File "/home/jon/devel/django/django/db/utils.py", line 94, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/jon/devel/django/django/utils/six.py", line 685, in reraise
 raise value.with_traceback(tb)
   File "/home/jon/devel/django/django/db/backends/utils.py", line 64, in
 execute
 return self.cursor.execute(sql, params)
   File "/home/jon/devel/django/django/db/backends/sqlite3/base.py", line
 334, in execute
 return Database.Cursor.execute(self, query, params)
 django.db.utils.OperationalError: no such table: auth_permission
 }}}

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

Re: [Django] #27234: Clarify the type of the django.server logger's 'request' extra context

2016-09-20 Thread Django

Comment (by Tim Graham):

No, I don't think the PR you mentioned has an effect on this.

From the documentation:

`django.request`: "Log messages related to the handling of requests."

`django.server`: Log messages related to the handling of requests received
by the server invoked by the `runserver` command.

If that distinction isn't clear, then I guess the documentation should be
clarified. Perhaps it was all less confusing before `runserver` was
modified to use logging (#25684).

My ideal scenario involves deprecating `runserver` in favor of a normal
wsgi runserver such as gunicorn (#21978) so that Django doesn't need to
maintain it's own minimal server, but it's unclear if it's feasible.

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

Re: [Django] #27076: Document django.contrib.admin.sites.AdminSite.register()

2016-09-20 Thread Django

#27076: Document django.contrib.admin.sites.AdminSite.register()
-+-
 Reporter:  Baptiste Mispelon|Owner:  Austin
 Type:   |  Simmons
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 [https://code.djangoproject.com/ticket/27076 PR] with comments for
 improvement.

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

Re: [Django] #23332: Change format of test runner output

2016-09-20 Thread Django

#23332: Change format of test runner output
-+-
 Reporter:  Philipp Metzler  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  1.5
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Following duplicate ticket #27255, a [https://groups.google.com/d/topic
 /django-developers/6nyN2PkpZik/discussion django-developers thread]
 proposes to reopen this 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/065.844d3b044c676f6836ae4247d14efd5b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27234: Clarify the type of the django.server logger's 'request' extra context

2016-09-20 Thread Django

Comment (by Ben Whale):

I'll leave that judgement to you.

Does #26688 standardise django.request and django.server so that they both
receive WSGIRequests or both receive sockets? This might effect
documentation changes for 1.11.

Because I'm curious, why have both django.request and django.server
loggers? The documentation implies that they do the same thing, after
#26688 they will log the same things and they both run when using
{{{python manage.py runserver}}}. Would it be sensible to look to removing
django.server in favour of django.request at some future point? For
example as an additional patch to 1.11 or even 1.12? If you think it's
worth looking into I'm happy to do some digging to find out what the
changes would look like (I want to learn more about the django internals
in any 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/067.65bb4e50b268b8a402c4dd4c25bcf45a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

#27255: Change test runner to display full dotted name of test
---+--
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 The mailing list is moderated for first-time posters.

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

Re: [Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

#27255: Change test runner to display full dotted name of test
---+--
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Chris Jerdonek):

 I posted a message to the django-developers list through the web interface
 after joining, but the message didn't show up in the web interface. Should
 the message have appeared already, or does the message need to be approved
 first?

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

Re: [Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

#27255: Change test runner to display full dotted name of test
---+--
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 That wasn't my understanding of the state of the Python issue. The title
 is still "Change format of test runner output" and statements like "I
 agree with Robert that the text output of the default runner should not be
 considered a part of the "api" that we make backwards compatible
 guarantees about." suggest to me that backwards compatibility isn't a
 concern.

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

Re: [Django] #26210: Make the SMTP more efficient if an error passes silently when creating a connection

2016-09-20 Thread Django

#26210: Make the SMTP more efficient if an error passes silently when creating a
connection
-+-
 Reporter:  Antonis  |Owner:  mlevental
  Christofides   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/7271 PR] looks good, pending a few
 cosmetic cleanups.

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

Re: [Django] #27240: Passing custom parameters to formset forms in admin

2016-09-20 Thread Django

#27240: Passing custom parameters to formset forms in admin
-+-
 Reporter:  Alexey Rogachev  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, form, | Triage Stage:
  formset, parameter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Did you come up with a solution? If so, maybe you can submit a patch if
 you still think an example is needed?

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

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

Re: [Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

Comment (by Chris Jerdonek):

The Python core developers don't consider this as a bug (and the default
output needs to remain the same anyways to preserve backwards
compatibility), and unittest already permits this to be easily customized,
so it's not clear to me what there is to "fix."

The final comment says this:

> Yes, making customising the output easier is a good thing. One way is to
use e.g. subunit.run (which can work with all unittest versions since 2.6)
and write a custom filter. Or a custom TestResult and TextTestRunner can
work too :)

The pull request I was planning to submit was to use a custom TestResult
as this commenter (as well as Michael Foord's comment) suggests.

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

Re: [Django] #27249: IntegrityError when using ManyToManyField.add() with a value of incorrect type (was: IntegrityError when using ManyToManyField.add due to type confusion)

2016-09-20 Thread Django

#27249: IntegrityError when using ManyToManyField.add() with a value of 
incorrect
type
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  manytomanyfield, | Triage Stage:  Accepted
  integrityerror |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I guess as long as the performance penalty isn't too large, a possibility
 could be to call `Field.to_python()` on the input.

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

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2016-09-20 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  Akshesh Doshi|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  index_together   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Akshesh Doshi):

 * keywords:   => index_together


Comment:

 Changed the keywords by mistake.

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

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2016-09-20 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  Akshesh Doshi|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 Akshesh Doshi):

 * keywords:  db-indexes index_together =>


Comment:

 Yes, since `AlterIndexTogether` is currently there in the migrations of so
 many Django projects we need to keep maintaining it. But the idea is to
 deprecate the use of `index_together` in the models file and the
 `generate_altered_index_together` method of the `MigrationAutodetector`.

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

Re: [Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

#27255: Change test runner to display full dotted name of test
---+--
 Reporter:  Chris Jerdonek |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 We reconsider wontfix tickets by reopening the original ticket after a
 discussion on the DevelopersMailingList yields a consensus to do so. In
 this case, I'd suggest you spend time contributing a fix to Python so that
 more people can ultimately benefit from your work.

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

[Django] #27255: Change test runner to display full dotted name of test

2016-09-20 Thread Django

#27255: Change test runner to display full dotted name of test
---+
Reporter: Chris Jerdonek | Owner: nobody
Type: Uncategorized | Status: new
Component: Testing framework |Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
At least twice in the past (#26659 and #23332), it has been suggested to
change Django's test runner to display the full dotted name of tests in
test output, for example:

{{{
FAIL: test_runner.test_discover_runner.DiscoverRunnerTest.test_output
}}}

instead of:

{{{
FAIL: test_output (test_runner.test_discover_runner.DiscoverRunnerTest)
}}}

The reasoning is that this is more convenient for developers: a failing
test could be rerun simply by copying and pasting the test name directly
from the test output, as is.

Previously, in #23332, this suggestion was closed with the following
reasoning:

> Django uses the built-in unittest library of Python, and the test output
is entirely handled by unittest. So there is nothing in Django which could
be changed to modify this output.

However, I don't think this summary is accurate because unittest makes it
very easy to change the test output (I would even say it facilitates
this), for example by exposing various subclass hooks on its test runner
and friends. Django indeed is

[https://github.com/django/django/blob/b5aac66b28c615b2bda63548cbd695dbb5a0c381/django/test/runner.py#L541
already doing this] and modifying the test output in certain cases using
`DebugSQLTextTestResult`. Django also customizes `unittest`'s test running
in other ways.

The customizability of test output is also supported by the
[http://bugs.python.org/issue22431#msg230957 following comment] by the
author of `unittest`, Michael Foord, in response to a request that this
change be made in unittest itself:

> I agree with Robert that the text output of the default runner should
not be considered a part of the "api" that we make backwards compatible
guarantees about. People who want to customise that should be customising
the text runner/result.

I hope you can reconsider. I put together a patch with tests and will
submit a PR shortly. You will see that the change is non-intrusive and
uses the customizability exposed by unittest.

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

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

Re: [Django] #27243: Make reverse_dict.getlist work with fully qualified module names

2016-09-20 Thread Django

#27243: Make reverse_dict.getlist work with fully qualified module names
---+--
 Reporter:  Etienne Robillard  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Core (URLs)|  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 Please reopen if you can add more details and provide a tested patch.

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

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

Re: [Django] #27253: Use assertIsInstance() in test_force_text_lazy

2016-09-20 Thread Django

#27253: Use assertIsInstance() in test_force_text_lazy
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 Okay, sorry.

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

Re: [Django] #27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes

2016-09-20 Thread Django

#27236: Deprecate Model.Meta.index_together in favour of Model.Meta.indexes
-+-
 Reporter:  akki |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
  index_together |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * version:   => master
 * stage:  Unreviewed => Accepted


Comment:

 My understanding is that we're keeping the `AlterIndexTogether` migration
 operation around indefinitely for support in historical migrations. Are
 there any other details from our conversations to add?

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

Re: [Django] #27253: Use assertIsInstance() in test_force_text_lazy

2016-09-20 Thread Django

#27253: Use assertIsInstance() in test_force_text_lazy
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 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 timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  Testing framework => Utilities
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


Comment:

 That would change the assertion such that the test wouldn't act as a
 regression test for the original issue. The test would pass if the fix in
 70be31bba7f8658f17235e33862319780c3dfad1 were reverted.

 By the way, the 'Testing Framework' ticket component is for `django.test`
 issues, not for issues with Django's test suite. Use whatever component
 the tests are related to, or "Core (Other)" for cleanups that affect
 multiple test apps.

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

Re: [Django] #27254: Detect management command context

2016-09-20 Thread Django

#27254: Detect management command context
---+--
 Reporter:  beruic |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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 timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 What about putting the code to be run when the server starts in `wsgi.py`?
 I'm not so sure if the prosed "context" idea is feasible.

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

[Django] #27254: Detect management command context

2016-09-20 Thread Django

#27254: Detect management command context
---+
Reporter: beruic | Owner: nobody
Type: New feature| Status: new
Component: Uncategorized |Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
I have some code in my project that generates some content for my pages
(compiles documentation).

I would like this code to run once every time the server starts, and
essentially I should use `AppConfig.ready()` to do this. However
`AppConfig.ready()` also runs when I run any management command, which is
very undesirrable, as I don't want to generate this content every time I
run unrelated tasks, such as `migrate`.

Therefore it would be nice to have a flag or some other means to detect if
code is currently running in the context a web server or not.

For now I have implemented this as a middleware which throws
`MiddlewareNotUsed` after generating the content.

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

[Django] #27253: Use assertIsInstance() in test_force_text_lazy

2016-09-20 Thread Django

#27253: Use assertIsInstance() in test_force_text_lazy
---+
 Reporter:  cjerdonek  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 It looks like it would be cleaner / simpler to be using
 `assertIsInstance()` here
 
([https://github.com/django/django/blob/b5aac66b28c615b2bda63548cbd695dbb5a0c381/tests/utils_tests/test_encoding.py#L35
 direct code link]):

 {{{#!python
 def test_force_text_lazy(self):
 s = SimpleLazyObject(lambda: 'x')
 self.assertTrue(issubclass(type(force_text(s)), six.text_type))
 }}}

 So it would be:

 {{{#!python
 def test_force_text_lazy(self):
 s = SimpleLazyObject(lambda: 'x')
 self.assertIsInstance(force_text(s), six.text_type)
 }}}

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

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

Re: [Django] #27229: Allow using aggregates in ModelAdmin.list_display

2016-09-20 Thread Django

#27229: Allow using aggregates in ModelAdmin.list_display
---+
 Reporter:  dorfire|Owner:  dorfire
 Type:  New feature|   Status:  assigned
Component:  contrib.admin  |  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
---+

Comment (by dorfire):

 I'll open a discussion in the mailing list. Thanks

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

Re: [Django] #27025: Python 3.6 compatibility

2016-09-20 Thread Django

#27025: Python 3.6 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
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:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"b5aac66b28c615b2bda63548cbd695dbb5a0c381" b5aac66b]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5aac66b28c615b2bda63548cbd695dbb5a0c381"
 Refs #27025 -- Fixed ArrayField querying on Python 3.6.

 Python 3.6 parses strings like '0_1' as numeric literals.
 http://bugs.python.org/issue26331
 }}}

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

Re: [Django] #27252: Remove hosting4django.net from DjangoFriendlyWebHosts

2016-09-20 Thread Django

#27252: Remove hosting4django.net from DjangoFriendlyWebHosts
-+-
 Reporter:  chhantyal|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 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 timgraham):

 * status:  new => closed
 * resolution:   => fixed
 * component:  Documentation => Uncategorized


Comment:

 done

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

Re: [Django] #18717: Setting attributes on deferred objects should trigger field's descriptor's set()

2016-09-20 Thread Django

#18717: Setting attributes on deferred objects should trigger field's 
descriptor's
__set__()
-+-
 Reporter:  Kronuz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 @Kronuz, is the issue still relevant (I was thinking
 7f51876f99851fdc3fef63aecdfbcffa199c26b9 might have helped)? If so, can
 you update the patch and add a test? Or at least add some more concrete
 steps to reproduce to help someone else contribute to the issue?

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

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

Re: [Django] #24082: Unique=True on TextField or CharField should not create an index

2016-09-20 Thread Django

#24082: Unique=True on TextField or CharField should not create an index
-+-
 Reporter:  djbug|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by edmorley):

 * cc: emorley@… (added)


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

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

Re: [Django] #23577: Rename operations should rename indexes, constraints, sequences and triggers named after their former value

2016-09-20 Thread Django

#23577: Rename operations should rename indexes, constraints, sequences and
triggers named after their former value
+
 Reporter:  CrimsonZen  |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by edmorley):

 * cc: emorley@… (added)


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

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

Re: [Django] #22125: Unnecessary creation of index for ManyToManyField

2016-09-20 Thread Django

#22125: Unnecessary creation of index for ManyToManyField
-+-
 Reporter:  tbhtan3@…|Owner:  bwreilly
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by edmorley):

 * cc: emorley@… (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/075.510ee09cfadc34150ab58c4cdad5cd9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27252: Remove hosting4django.net from DjangoFriendlyWebHosts

2016-09-20 Thread Django

#27252: Remove hosting4django.net from DjangoFriendlyWebHosts
-+-
 Reporter:  chhantyal|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 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
-+-
Changes (by chhantyal):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> This site http://hosting4django.net no longer exists and domain is
> parked.
>
> Please remove it from DjangoFriendlyWebHosts

New description:

 These sites don't offer django hosting anymore:

 1.  http://hosting4django.net  - no longer exists and domain is parked.
 2. http://hosting.djangofoo.com - no longer exists

 Please remove them from DjangoFriendlyWebHosts

--

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

Re: [Django] #16682: KeyboardInterrupt not handled properly in transaction aborting

2016-09-20 Thread Django

#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (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 timgraham):

 * Attachment "16682-atomic.diff" added.


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

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

Re: [Django] #16682: KeyboardInterrupt not handled properly in transaction aborting

2016-09-20 Thread Django

#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (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 timgraham):

 `transaction.atomic()` doesn't seem to suffer from this issue. Is there
 any value in adding the test (an updated one is attached)?

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

[Django] #27252: Remove hosting4django.net from DjangoFriendlyWebHosts

2016-09-20 Thread Django

#27252: Remove hosting4django.net from DjangoFriendlyWebHosts
--+
 Reporter:  chhantyal |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 This site http://hosting4django.net no longer exists and domain is parked.

 Please remove it from DjangoFriendlyWebHosts

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

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

Re: [Django] #21251: Not all database backends support grouping by a column number

2016-09-20 Thread Django

#21251: Not all database backends support grouping by a column number
-+-
 Reporter:  manfre   |Owner:  manfre
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  mssql| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Please reopen if needed.

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

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

Re: [Django] #27223: model RangeField with default value are skiped in ModelForm full_clean validation in construct_instance function

2016-09-20 Thread Django

#27223: model RangeField with default value are skiped in ModelForm full_clean
validation in construct_instance function
-+--
 Reporter:  taxido   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by taxido:

Old description:

> https://github.com/django/django/commit/4bc6b939944183533ae74791d21282e613f63a96
> That change in construct_instance function makes a bug with custom
> full_clean validation for *RangeField like fields
>
> RangeField values are send in POST method by two key=value pair:
> my_range_0=1_range_1=9
> that there is not my_range field in POST so field value is skipped and
> not copied to instance.

New description:

 Yes, this patch fix this.
 Thank you, and I waiting for 1.10.2 shortly

--

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

Re: [Django] #27223: model RangeField with default value are skiped in ModelForm full_clean validation in construct_instance function

2016-09-20 Thread Django

#27223: model RangeField with default value are skiped in ModelForm full_clean
validation in construct_instance function
-+--
 Reporter:  taxido   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by taxido):

 Yes, this patch fix this.
 Thank you, and I waiting for 1.10.2 shortly

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

Re: [Django] #27223: model RangeField with default value are skiped in ModelForm full_clean validation in construct_instance function

2016-09-20 Thread Django

#27223: model RangeField with default value are skiped in ModelForm full_clean
validation in construct_instance function
-+--
 Reporter:  taxido   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by taxido:

Old description:

> Yes, this patch fix this.
> Thank you, and I waiting for 1.10.2 shortly

New description:

 >
 
https://github.com/django/django/commit/4bc6b939944183533ae74791d21282e613f63a96
 > That change in construct_instance function makes a bug with custom
 > full_clean validation for *RangeField like fields
 >
 > RangeField values are send in POST method by two key=value pair:
 > my_range_0=1_range_1=9
 > that there is not my_range field in POST so field value is skipped and
 > not copied to instance.

--

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

Re: [Django] #27251: Cannot combine multiple SearchQuery objects

2016-09-20 Thread Django

#27251: Cannot combine multiple SearchQuery objects
--+--
 Reporter:  jaap3 |Owner:
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => duplicate
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Should be fixed in #27143.

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

Re: [Django] #27250: Confusing assignment with CheckboxSelectMultiple

2016-09-20 Thread Django

#27250: Confusing  assignment with CheckboxSelectMultiple
-+-
 Reporter:  lamda|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CheckboxSelectMultiple label   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * version:  1.10 => master
 * stage:  Unreviewed => Accepted


Comment:

 +1 for removing the `for` attribute.

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

[Django] #27251: Cannot combine multiple SearchQuery objects

2016-09-20 Thread Django

#27251: Cannot combine multiple SearchQuery objects
--+--
 Reporter:  jaap3 |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 According to the docs:

 
[https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/#searchquery
 SearchQuery]  terms can be combined logically to provide more flexibility

 This works for two SearchQuery objects

 {{{
 >>> SearchQuery('foo') | SearchQuery('bar')
 
 }}}

 But any more than that and an exception is raised:

 {{{
 >>> SearchQuery('foo') | SearchQuery('bar') | SearchQuery('baz')
 NotImplementedError: Use .bitand() and .bitor() for bitwise logical
 operations.
 }}}

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

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 I don't think a meta option for this special case is worth it but a flag
 to prevent Django from implicitly adding an auto-incrementing primary key
 when none is explicitly specified could be useful in multiple cases
 (migrations comes to mind here) and leveraged in this one.

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

Re: [Django] #27250: Confusing assignment with CheckboxSelectMultiple

2016-09-20 Thread Django

#27250: Confusing  assignment with CheckboxSelectMultiple
-+-
 Reporter:  lamda|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  CheckboxSelectMultiple label   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Keeping the label but removing the `for` attribute seems like safer option
 to me.

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

Re: [Django] #27217: makemigrations crashes with "'SpatialRefSysMixin' has no attribute '_meta'" on PostGIS

2016-09-20 Thread Django

#27217: makemigrations crashes with "'SpatialRefSysMixin' has no attribute 
'_meta'"
on PostGIS
-+
 Reporter:  MVSatish |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 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
-+

Comment (by charettes):

 Not so far but it should be only a matter of adjusting
 
[https://github.com/django/django/blob/911d9f4ed1a39f945769b7198a419850378f9824/django/db/migrations/operations/models.py#L112
 this line] to also check for `isinstance(base, models.base.ModelBase)`.

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

[Django] #27250: Confusing assignment with CheckboxSelectMultiple

2016-09-20 Thread Django

#27250: Confusing  assignment with CheckboxSelectMultiple
+--
 Reporter:  lamda   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.10
 Severity:  Normal  |   Keywords:  CheckboxSelectMultiple label
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 Using CheckboxSelectMultiple leads to a (in my opinion) confusing
 assignment of the  in the generated HTML. The general label for the
 choices refers to the first element in the list. Please see this example:

 forms.py:
 {{{
 class TestForm(forms.Form):
 days = forms.MultipleChoiceField(
 widget=forms.CheckboxSelectMultiple,
 choices=[('1', 'DayOne'), ('2', 'DayTwo')],
 )
 }}}

 views.py:
 {{{
 def form(request):
 return render(request, 'form.html', {'form': forms.TestForm()})
 }}}
 form.html:
 {{{
 
   
 {{ form.as_ul }}
   
   Submit
 
 }}}

 Resulting HTML (prettified):
 {{{
 
   
 
   Days:
   
 
DayOne
 
 
DayTwo
 
   
 
   
   Submit
 
 }}}

 This means that clicking on "Days" selects the first day. I would suggest
 to remove the " element and only keep the label text itself.

 Compare this to the HTML when not having the CheckboxSelectMultiple
 widget, where clicking on "Days" simply selects the  element:
 {{{
 
   
 
   Days:
   
 One
 Two
   
 
   
   Submit
 
 }}}

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

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 Yes, you're right. Sorry for the noise! I mistakenly thought it was Django
 throwing an error.

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

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jaap3):

 As far as Django is concerned these views do have a primary key (there's a
 id field, it even has a unique index). The problem is that at the database
 level this field isn't, and cannot, have a primary key constraint. Without
 a **real** primary key Postgres cannot group by primary key only, since
 they don't exist.

 This is what happens if you try to add a PK to a (materialized) view:

 {{{
 => ALTER MATERIALIZED VIEW my_view ADD CONSTRAINT my_view_pkey PRIMARY KEY
 (id);
 ERROR:  "my_view" is not a table
 }}}

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * cc: jarshwah (added)


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

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

#27241: Annotate doesn't work with PostgreSQL views anymore
-+-
 Reporter:  jaap3|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgresql view  | Triage Stage:  Accepted
  aggregate annotate |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 Can you try adding a field as a primary key on the view? Ideally each row
 would have a unique key in a view (I know this isn't always the case), but
 if you just **tell** Django that your unmanaged model has a primary key,
 it'll try to group on that.

 For what it's worth I've always been a big user of unmanaged models over
 views - so I'm keen to see this resolved and not abandoned.

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

Re: [Django] #27241: Annotate doesn't work with PostgreSQL views anymore

2016-09-20 Thread Django

Comment (by jaap3):

I don't known if disabling the optimisation for all unmanaged models is
the right choice. It seems that this is a fairly esoteric edge case. The
fact that this behaviour was changed in 1.9 and almost nobody has noticed
until now speaks for itself (I can only find one other issue that looks
similar: #26758).

I'm sure that most unmanaged models are normal database tables with a
primary key constraint. It would be a shame to have to disable something
that works fine for the vast majority of use cases just because of this
one edge case.

Instead, would it be feasible to be able to opt-out of the optimisation by
setting a flag on the model's Meta class? So instead of checking if
`managed` is `False`, Django could check if `allows_group_by_selected_pks`
is set to `False` for the model and then choose not to perform the related
optimisation.

I am actively maintaining this application and would have no qualms about
adding a flag to the few models affected by this issue. If anyone else
runs into this the must also be actively maintaining theirs so they can do
the same thing.

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

[Django] #27249: IntegrityError when using ManyToManyField.add due to type confusion

2016-09-20 Thread Django

#27249: IntegrityError when using ManyToManyField.add due to type confusion
-+-
 Reporter:  sjoerdjob|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  master
  (models, ORM)  |   Keywords:  manytomanyfield,
 Severity:  Normal   |  integrityerror
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 When specifying the primary keys of objects to `related_manager.add`, one
 has to use the same type as the database returns, at the risk of getting
 an `IntegrityError`.

 Example (using Django contrib.auth).

 {{{
 >>> from django.contrib.auth.models import Group, Permission
 >>> group = Group.objects.create()
 >>> permission = Permission.objects.first()
 >>> print(permission.pk)
 1
 >>> group.permissions.add(permission.pk)
 >>> group.permissions.add(permission.pk)
 >>> group.permissions.add(str(permission.pk))
 Traceback (most recent call last):
 ...  ...
 IntegrityError: UNIQUE constraint failed: auth_group_permissions.group_id,
 auth_group_permissions.permission_id
 >>> group.permissions.add(permission.pk)
 >>> group.permissions.add(permission.pk)
 }}}

 Now of course, I assume nobody would do an explicit call to `str()` there,
 but if the primary keys come from another input source (like: a URL), it
 is not unlikely to expect them to not be the same type as the database
 uses.

 (seen in 1.9.6, 1.10.1 and master).

 Not sure about how to fix it, because the type of the primary key might
 not necessarily be an integer.

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

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

56 matches

Mail list logo