Re: [Django] #27823: Use python-home in WSGI daemon installation documentation

2017-02-13 Thread Django 
#27823: Use python-home in WSGI daemon installation documentation
-+-
 Reporter:  Avi  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  wsgi installation| Triage Stage:  Accepted
  apache |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"5044d18e1fca657628a407542f9f76e00cab3262" 5044d18e]:
 {{{
 #!CommitTicketReference repository=""
 revision="5044d18e1fca657628a407542f9f76e00cab3262"
 [1.10.x] Fixed #27823 -- Updated mod_wsgi example to use WSGIPythonHome.

 Backport of 103e6cf26c17ae650b7caa3956b87a215334d761 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/068.691d6678cdd64f1fee58b4fbdf5372d2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27823: Use python-home in WSGI daemon installation documentation

2017-02-13 Thread Django 
#27823: Use python-home in WSGI daemon installation documentation
-+-
 Reporter:  Avi  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  wsgi installation| Triage Stage:  Accepted
  apache |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"8bf9967e7b0bdc7edc4c616a3be4027c73176513" 8bf9967]:
 {{{
 #!CommitTicketReference repository=""
 revision="8bf9967e7b0bdc7edc4c616a3be4027c73176513"
 [1.11.x] Fixed #27823 -- Updated mod_wsgi example to use WSGIPythonHome.

 Backport of 103e6cf26c17ae650b7caa3956b87a215334d761 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/068.bbdaa247227c571532300ff749f56463%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27823: Use python-home in WSGI daemon installation documentation

2017-02-13 Thread Django 
#27823: Use python-home in WSGI daemon installation documentation
-+-
 Reporter:  Avi  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  wsgi installation| Triage Stage:  Accepted
  apache |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"103e6cf26c17ae650b7caa3956b87a215334d761" 103e6cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="103e6cf26c17ae650b7caa3956b87a215334d761"
 Fixed #27823 -- Updated mod_wsgi example to use WSGIPythonHome.
 }}}

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

Re: [Django] #27829: Deprecate DEFAULT_CONTENT_TYPE setting

2017-02-13 Thread Django 
#27829: Deprecate DEFAULT_CONTENT_TYPE setting
--+
 Reporter:  Adam Chainz   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  1.11
 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 Tim Graham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27833: prefetch_related fails with SQLite when used with 1000 parent records

2017-02-13 Thread Django 
#27833: prefetch_related fails with SQLite when used with 1000 parent records
-+-
 Reporter:  Jason Barnabe|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Old description:

> This is described in
> https://code.djangoproject.com/ticket/16937#comment:3, but I don't see
> any issue filed for it.
>
> "[prefetch_related] will not work on some backends if you have a lot of
> objects in your queryset. For example the SQLite backend has a limitation
> of 999 parameters to single SQL query, so if you have 1000 objects,
> prefetch_related will fail as you need to supply 1000 id values to the
> query."'
>
> Batch it up like in #16426 and #17788, which dealt with the same
> limitation?

New description:

 This is described in ticket:16937#comment:3, but I don't see any issue
 filed for it.

 "[prefetch_related] will not work on some backends if you have a lot of
 objects in your queryset. For example the SQLite backend has a limitation
 of 999 parameters to single SQL query, so if you have 1000 objects,
 prefetch_related will fail as you need to supply 1000 id values to the
 query."'

 Batch it up like in #16426 and #17788, which dealt with the same
 limitation?

--

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

Re: [Django] #27820: RequestDataTooBig/TooManyFields fail to render the debug page

2017-02-13 Thread Django 
#27820: RequestDataTooBig/TooManyFields fail to render the debug page
-+-
 Reporter:  Amalia Souček|Owner:  Amalia
 |  Souček
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  DATA_UPLOAD_MAX_MEMORY_SIZE,   |
  RequestDataTooBig, |
  response_for_exception, 500|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"e399272bed9cf28634a6866bea9bb74c71159291" e399272]:
 {{{
 #!CommitTicketReference repository=""
 revision="e399272bed9cf28634a6866bea9bb74c71159291"
 [1.10.x] Fixed #27820 -- Fixed RequestDataTooBig/TooManyFieldsSent crash.

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

Re: [Django] #27820: RequestDataTooBig/TooManyFields fail to render the debug page

2017-02-13 Thread Django 
#27820: RequestDataTooBig/TooManyFields fail to render the debug page
-+-
 Reporter:  Amalia Souček|Owner:  Amalia
 |  Souček
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  DATA_UPLOAD_MAX_MEMORY_SIZE,   |
  RequestDataTooBig, |
  response_for_exception, 500|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2f10216f84b55920de25422842a66260219e393f" 2f10216]:
 {{{
 #!CommitTicketReference repository=""
 revision="2f10216f84b55920de25422842a66260219e393f"
 Fixed #27820 -- Fixed RequestDataTooBig/TooManyFieldsSent crash.
 }}}

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

Re: [Django] #27820: RequestDataTooBig/TooManyFields fail to render the debug page

2017-02-13 Thread Django 
#27820: RequestDataTooBig/TooManyFields fail to render the debug page
-+-
 Reporter:  Amalia Souček|Owner:  Amalia
 |  Souček
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  DATA_UPLOAD_MAX_MEMORY_SIZE,   |
  RequestDataTooBig, |
  response_for_exception, 500|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b54fff293846d24b3345a86fea223c93926e0c86" b54fff2]:
 {{{
 #!CommitTicketReference repository=""
 revision="b54fff293846d24b3345a86fea223c93926e0c86"
 [1.11.x] Fixed #27820 -- Fixed RequestDataTooBig/TooManyFieldsSent crash.

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

Re: [Django] #27834: Add the STRPOS database function

2017-02-13 Thread Django 
#27834: Add the STRPOS database function
-+-
 Reporter:  Baptiste Mispelon|Owner:  Brad
 |  Melin
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Brad Melin):

 * owner:  nobody => Brad Melin
 * 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/067.4fb35d93197abee104a9b8a445e479c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27835: Make TransactionTestCase raise an error if it accesses non-default database connection without multi_db=True

2017-02-13 Thread Django 
#27835: Make TransactionTestCase raise an error if it accesses non-default 
database
connection without multi_db=True
---+
 Reporter:  Tim Graham |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * Attachment "27835.diff" added.


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

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

[Django] #27835: Make TransactionTestCase raise an error if it accesses non-default database connection without multi_db=True

2017-02-13 Thread Django 
#27835: Make TransactionTestCase raise an error if it accesses non-default 
database
connection without multi_db=True
-+
   Reporter:  Tim Graham |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Suggested by Simon on [https://github.com/django/django/pull/8035 my PR]
 to fix some test isolation problems, `TransactionTestCase` and its
 subclasses could raise an error if they make queries on non-default
 databases. A rough sketch of this could be implemented 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/052.9416f2d6b5126a760fc7e541f05ce38b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.10
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  invalid
 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 Hervé Cauwelier):

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


Comment:

 OK I missed the point when hints contains "model_name" and it's extracted
 and passed as an argument to allow_migration().

 So yes indeed it was triggering the code path in my router when
 "model_name" is defined.

 This patch in django just prevented passing a "model_name" argument in the
 first place, but any name would do, even "foobar".

 Closing this ticket, thank you for your time.

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

Re: [Django] #27834: Add the STRPOS database function

2017-02-13 Thread Django 
#27834: Add the STRPOS database function
-+-
 Reporter:  Baptiste Mispelon|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by David Adler):

 * stage:  Unreviewed => Accepted


Comment:

 This seems valid to me maybe it could be called something like `Indexstr`
 to be in keeping with `'asdf'.index('s')`?

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

[Django] #27834: Add the STRPOS database function

2017-02-13 Thread Django 
#27834: Add the STRPOS database function
-+-
   Reporter:  Baptiste   |  Owner:  nobody
  Mispelon   |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Django currently ships with a dozen or so database functions [1].

 I recently had the need for what postgres calls `STRPOS(string,
 substring)` to find the position of a string inside a substring and was
 surprised to find it was not included in the list of builtins.

 I'm not sure if there's an official criteria for deciding which functions
 get implemented in core, but I did some quick research and found that this
 `STRPOS()` functionality at least seems to be present in all 4 officially
 supported databases:

 * **Postgres**: `STRPOS(string, substring)` [2]
 * **Sqlite**: `INSTR(string, substring)` [3]
 * **MySQL**: `LOCATE(substring, string)` [4]
 * **Oracle**: `INSTR(string, substring)` [5]

 The names and order of arguments are somewhat inconsistent but the
 behavior and return value of the function seems well-defined: it returns a
 positive integer corresponding to the (1-indexed) position of the
 substring inside the string; if the substring is not found, 0 is returned.


 I'm marking this as "easy pickings" because other than the inconsistent
 naming and argument order, the actual implementation of the `Func`
 shouldn't be too complex.

 [1] https://docs.djangoproject.com/en/dev/ref/models/database-functions/
 [2] https://www.postgresql.org/docs/current/static/functions-string.html
 [3] https://www.sqlite.org/lang_corefunc.html#instr
 [4] https://dev.mysql.com/doc/refman/5.7/en/string-
 functions.html#function_locate
 [5]
 https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions068.htm

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

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.10
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hervé Cauwelier):

 Oops! I've added some print()s in my code to discover it was just a
 coincidence if the router didn't choke on KeyError. With the patch, it's
 trigerring another code path or something, let me sort this out 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/063.659153eabe1d7550ac695d31c5a93458%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27833: prefetch_related fails with SQLite when used with 1000 parent records

2017-02-13 Thread Django 
#27833: prefetch_related fails with SQLite when used with 1000 parent records
-+-
   Reporter:  Jason  |  Owner:  nobody
  Barnabe|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  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  |
-+-
 This is described in
 https://code.djangoproject.com/ticket/16937#comment:3, but I don't see any
 issue filed for it.

 "[prefetch_related] will not work on some backends if you have a lot of
 objects in your queryset. For example the SQLite backend has a limitation
 of 999 parameters to single SQL query, so if you have 1000 objects,
 prefetch_related will fail as you need to supply 1000 id values to the
 query."'

 Batch it up like in #16426 and #17788, which dealt with the same
 limitation?

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

Re: [Django] #27825: ORM Object constructor does not cast types of it's attributes when called by reference

2017-02-13 Thread Django 
#27825: ORM Object constructor does not cast types of it's attributes when 
called
by reference
-+-
 Reporter:  Oleg Belousov|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM  | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 You can add in a `model.full_clean()` if you want to coerce the values to
 the correct type.

 I raised the topic on the [https://groups.google.com/d/msg/django-
 developers/3IX1zH09Idg/s7mSmWZhBgAJ django-developers mailing list].
 Perhaps you'd like to elaborate on your ideas 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.1f4a1d9d9186e4e4fdd2a02d769d75ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.10
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hervé Cauwelier):

 I always assumed you meant Django 1.10 and later. Django 1.8 and 1.9
 happily lived with this typo. :-)

 So we could just leave both keys without a deprecation path and that
 migration will naturally disappear when migrations are squashed?

 As for the added value of this fix, it would avoid me to write a special
 case in my database router when "model_name" is "contenttype".

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

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.10
  contrib.contenttypes   |
 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 Tim Graham):

 * severity:  Release blocker => Normal


Comment:

 Now that I see that migration was added in Django 1.8, I'm not sure if
 there's much value in fixing this. 1.8/1.9 only receive security fixes at
 this point. Does the fix have some value if it's changed in later versions
 of Django?

 Separately, we might consider a strategy for squashing contrib app
 migrations so we can eventually remove obsolete migrations like that 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.53a8d6686a05d797bbee969f217da449%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22669: bulk_create with empty model fields fails on oracle

2017-02-13 Thread Django 
#22669: bulk_create with empty model fields fails on oracle
-+-
 Reporter:  sns1081@…|Owner:  Michael
 |  Nacharov
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
  QuerySet.bulk_create   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"3effe3a9c63cd461a1ea7c42bab0e8fbc34b0c53" 3effe3a9]:
 {{{
 #!CommitTicketReference repository=""
 revision="3effe3a9c63cd461a1ea7c42bab0e8fbc34b0c53"
 Refs #22669 -- Fixed bulk_create test if Pillow isn't installed.
 }}}

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

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.10
  contrib.contenttypes   |
 Severity:  Release blocker  |   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 Hervé Cauwelier):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
-+-
 Reporter:  Hervé Cauwelier  |Owner:  Hervé
 |  Cauwelier
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.10
  contrib.contenttypes   |
 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 Hervé Cauwelier):

 * owner:  nobody => Hervé Cauwelier
 * status:  new => assigned


Comment:

 I guess it's a low-hanging fruit for a newcomer like me, assigning it to
 myself.

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

Re: [Django] #27828: ORM crash on F('date_field') - F('int_field') on PostgreSQL

2017-02-13 Thread Django 
#27828: ORM crash on F('date_field') - F('int_field') on PostgreSQL
-+-
 Reporter:  Vytis Banaitis   |Owner:  Vytis
 |  Banaitis
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (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 Tim Graham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27766: runserver crashes because of auto-reloader (Py3 + PowerShell)

2017-02-13 Thread Django 
#27766: runserver crashes because of auto-reloader (Py3 + PowerShell)
---+--
 Reporter:  oTree-org  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 As I said before, "To accept the ticket, we need an explanation of why
 Django (and not, for example, Python or PowerShell) is at fault." Please
 don't reopen the ticket without that explanation.

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

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

Re: [Django] #26626: Update decorator_from_middleware to work with new-style middleware

2017-02-13 Thread Django 
#26626: Update decorator_from_middleware to work with new-style middleware
---+--
 Reporter:  Tim Graham |Owner:  Carl Meyer
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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 Andreas Pelme):

 Another use case:

 We have a custom authentication mechanism that is not tied to
 contrib.admin for our main site.

 However, we use contrib.auth for administrative accounts. To make it very
 clear which views needs a real user, we have disabled the auth middleware
 globally and use a custom admin site that selectively enables auth:

 {{{
 from django.contrib import admin
 from django.contrib.auth.middleware import AuthenticationMiddleware

 from django.utils.decorators import decorator_from_middleware


 auth_decorator = decorator_from_middleware(AuthenticationMiddleware)


 class AdminSite(admin.AdminSite):
 def admin_view(self, view, cacheable=False):
 super_wrapper = super().admin_view(view, cacheable=cacheable)
 return auth_decorator(super_wrapper)
 }}}


 (This use case is fine and works fine in Django 1.10 since Django's built
 in `AuthenticationMiddleware` is both old and new-style, but I just wanted
 to highlight that `decorator_from_middleware` is useful in different
 contexts)

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

Re: [Django] #27829: Deprecate DEFAULT_CONTENT_TYPE setting (was: Deprecate DEFAULT_CONTENT_TYPE)

2017-02-13 Thread Django 
#27829: Deprecate DEFAULT_CONTENT_TYPE setting
--+
 Reporter:  Adam Chainz   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  HTTP handling |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


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

Re: [Django] #23908: settings.DEFAULT_CONTENT_TYPE = "application/xhtml+xml" breaks admin site (was: XHTML breaks admin site)

2017-02-13 Thread Django 
#23908: settings.DEFAULT_CONTENT_TYPE = "application/xhtml+xml" breaks admin 
site
-+-
 Reporter:  Brian May|Owner:  Anton
 |  Samarchyan
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Thanks for replying. #27829 will deprecate
 `settings.DEFAULT_CONTENT_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/063.1d025abed175b80286b165ca056a76b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26626: Update decorator_from_middleware to work with new-style middleware

2017-02-13 Thread Django 
#26626: Update decorator_from_middleware to work with new-style middleware
---+--
 Reporter:  Tim Graham |Owner:  Carl Meyer
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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 Andreas Pelme):

 A use case for this is tests. I have a middleware that handles temporary
 unavailability by showing a loading page/returning HTTP 503 for certain
 exceptions.

 This particular middleware uses custom logic in `__call__` and
 `process_exception`. `decorator_from_middleware` makes it easy to test
 this middleware:

 {{{
 @override_settings(MAINTENANCE_MODE=True)
 def test_maintenance_mode(self):
 @decorator_from_middleware(TemporaryUnavailable)
 def view():
  raise AssertionError("don't call")
 response  = view(RequestFactory().get('/')
 assert response.status_code == 503
 }}}


 Of course, I could craft my own get_response, initiate the middleware and
 call `__call__` or `process_exception` directly but that is ugly and easy
 to get some details wrong, especially when the test involves exceptions.

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

Re: [Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
--+
 Reporter:  Hervé Cauwelier   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  1.10
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * component:  Migrations => contrib.contenttypes
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 For backwards compatibility at this point, I guess we should add `'model'`
 there instead of renaming `'model_name'`.

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

Re: [Django] #27830: Use distutils.version.LooseVersion instead of custom version parsing

2017-02-13 Thread Django 
#27830: Use distutils.version.LooseVersion instead of custom version parsing
--+
 Reporter:  NotSqrt   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Core (Other)
 * 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.c24b410486d105107cd4e8d1da0f2524%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27831: decorator_from_middleware is not compatible with new middlewares

2017-02-13 Thread Django 
#27831: decorator_from_middleware is not compatible with new middlewares
---+--
 Reporter:  Andreas Pelme  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Utilities  |  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 Tim Graham):

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


Comment:

 Duplicate of #26626. Could you add your use case to that ticket?

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

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

[Django] #27832: contenttypes migration not following the doc on hints naming

2017-02-13 Thread Django 
#27832: contenttypes migration not following the doc on hints naming
---+
   Reporter:  Hervé Cauwelier  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Migrations   |Version:  1.10
   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|
---+
 Hi,

 The second migration for contenttypes provides a RunPython operation:
 
https://github.com/django/django/blob/master/django/contrib/contenttypes/migrations/0002_remove_content_type_name.py#L33

 As you can see on the highlighted line, the hint is named "model_name".

 But the doc suggests the key should be "model":
 https://docs.djangoproject.com/en/1.10/topics/db/multi-db/#allow_migrate

 Not a big issue but I ran into this when writing the "allow_migrate"
 method of a database router.

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

Re: [Django] #27766: runserver crashes because of auto-reloader (Py3 + PowerShell)

2017-02-13 Thread Django 
#27766: runserver crashes because of auto-reloader (Py3 + PowerShell)
---+--
 Reporter:  oTree-org  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 urbanit):

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


Comment:

 Same situation here, windows 10 pro 1607 // pyhton 3.6 // Django 1.10.5

 Thanks @oTree-org for the workaround with --noreload

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

[Django] #27831: decorator_from_middleware is not compatible with new middlewares

2017-02-13 Thread Django 
#27831: decorator_from_middleware is not compatible with new middlewares
-+
   Reporter:  Andreas Pelme  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Utilities  |Version:  1.10
   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  |
-+
 The old middlewares is deprecated, but `decorator_from_middleware` assumes
 old style middleware and does not work with the new style.

 `decorator_from_middleware` is very useful, not having it for new
 middlewares is a bummer.

 Currently, one needs to use `django.utils.deprecation.MiddlewareMixin` to
 use it with newly written middlewares.

 I'm not sure if it is possible to support both styles with
 `decorator_from_middleware` since the API:s (passing `get_response`) is
 different.

 Maybe the best way forward would be to introduce a new util function that
 deals with the new style middleware?

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

[Django] #27830: Use distutils.version.LooseVersion instead of custom version parsing

2017-02-13 Thread Django 
#27830: Use distutils.version.LooseVersion instead of custom version parsing
-+
   Reporter:  NotSqrt|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  1.10
   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  |
-+
 Hi !

 As discussed with Tim Graham in [https://groups.google.com/forum/#!topic
 /django-users/BM3d679AsyA]

 `django/db/backends/postgresql_psycopg2/base.py:psycopg2_version` can't
 handle versions like `2.7b1` or
 
`2.7b2.dev0`([[https://github.com/psycopg/psycopg2/commit/b4b8b5f16440d11f8551be23c3f7517e060cf274|the
 current git versions]]), because it only returns `(2, )`, which is lower
 than the minimal requirement of `(2, 4, 5)`.

 A possibility is to use :
 {{{
   from distutils.version import LooseVersion
   LooseVersion(psycopg2.__version__.split(' ', 1)[0]) >=
 LooseVersion('2.4.5')
 }}}

 Another possibility is
 [[https://packaging.pypa.io/en/latest/version/|packaging]], the reference
 implementation of [[https://www.python.org/dev/peps/pep-0440/|PEP-440]],
 which is a dependency of setuptools (previously included in its vendor
 libs), so very probably installed everywhere !

 While searching for "version" in the django code base, there appears to be
 multiple regex used to parse version strings : mysql, postgresql, gdal,
 geos.
 This could probably be more DRY, and correct.

 I've seen things like `if geos_version_info()['version'] < '3.3.0':`,
 which might fail at some point.

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