date:20161227

Re: [Django] #8851: Add a default option to list_filter in the admin interface

2016-12-27 Thread Django

#8851: Add a default option to list_filter in the admin interface
-+-
 Reporter:  Riskable |Owner:  Harro
 |
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, list_filter,  | Triage Stage:  Ready for
  default|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Asif Saifuddin Auvi):

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


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

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

Re: [Django] #27638: Rollback data changes made inside templates

2016-12-27 Thread Django

Comment (by Simon Charette):

Coupling the database layer with the template one looks like a really bad
idea to me.

What if you want to use the template layer without configuring a database?
What if your template ends up taking a lot of time to render and keeps a
transaction open the whole time?

While the `alters_data` approach is not perfect I think that it offers a
good enough solution paired with a convention of naming functions and
methods appropriately.

Now a small things that could be done to improve the situation could be to
either automatically mark overridden `save()`/`delete()` methods as
`alters_data = True` in `ModelBase.__new__` or have system checks to warn
developers about this edge 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/072.0951b7d85cd4ead4f09735e39f60f316%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15667: Implement template-based widget rendering

2016-12-27 Thread Django

#15667: Implement template-based widget rendering
+
 Reporter:  Bruno Renié |Owner:  (none)
 Type:  New feature |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  form-rendering  | 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):

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


Comment:

 In b52c73008a9d67e9ddbb841872dc15cdd3d6ee01:

 Fixed #15667 -- Added template-based widget rendering.

 Thanks Carl Meyer and Tim Graham for contributing to the 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/066.45ddde145a950442bcf63b673264c0d5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27648: Deprecate ("iLmsu") regex groups in URLpatterns

2016-12-27 Thread Django

#27648: Deprecate ("iLmsu") regex groups in URLpatterns
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"51cde873d9fc8e4540f4efecbd39cfe8e770be38" 51cde87]:
 {{{
 #!CommitTicketReference repository=""
 revision="51cde873d9fc8e4540f4efecbd39cfe8e770be38"
 Fixed #27648 -- Deprecated (iLmsu) regex groups in url() patterns.
 }}}

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

Re: [Django] #27640: HTTPResponse.repr errors when Content-Type header is not defined

2016-12-27 Thread Django

#27640: HTTPResponse.__repr__ errors when Content-Type header is not defined
-+-
 Reporter:  Adam Chainz  |Owner:  roboslone
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"544b2ef29f0f2577912f88cf746ae0ca5877b5f8" 544b2ef2]:
 {{{
 #!CommitTicketReference repository=""
 revision="544b2ef29f0f2577912f88cf746ae0ca5877b5f8"
 Fixed #27640 -- Fixed HttpResponse's __repr__()  without a 'Content-Type'
 header.
 }}}

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

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

Re: [Django] #26423: Make EmailValidator use HTML5 validation rather than more complicated regular expressions

2016-12-27 Thread Django

#26423: Make EmailValidator use HTML5 validation rather than more complicated
regular expressions
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * needs_docs:  0 => 1


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

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

Re: [Django] #27640: HTTPResponse.repr errors when Content-Type header is not defined

2016-12-27 Thread Django

#27640: HTTPResponse.__repr__ errors when Content-Type header is not defined
-+-
 Reporter:  Adam Chainz  |Owner:  roboslone
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #24994: Document expectations about settings.SECRET_KEY type (was: Document/check that settings.SECRET_KEY should be a valid unicode string)

2016-12-27 Thread Django

#24994: Document expectations about settings.SECRET_KEY type
-+-
 Reporter:  Baptiste Mispelon|Owner:  MaartenPI
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 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):

 * needs_better_patch:  1 => 0
 * component:  Core (System checks) => Documentation


Comment:

 Following the django-developers discussion, it seems there isn't consensus
 for this check after all. I've created a
 [https://github.com/django/django/pull/7750 PR] to document the
 expectation about the type of the secret key.

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

Re: [Django] #27647: runserver segfaults with autoreload enabled on Windows 10 (was: Django runserver segfaults with autoreload enabled on Windows 10)

2016-12-27 Thread Django

#27647: runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:  Ready for
  autoreload autoreload.py noreload  |  checkin
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Ready for checkin


Comment:

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

Re: [Django] #27648: Deprecate ("iLmsu") regex groups in URLpatterns

2016-12-27 Thread Django

#27648: Deprecate ("iLmsu") regex groups in URLpatterns
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marten Kenbeek):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #27645: Move Settings.init checks to system checks

2016-12-27 Thread Django

#27645: Move Settings.__init__ checks to system checks
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I noticed "Django will refuse to start if :setting:`SECRET_KEY` is not
 set." in `docs/ref/settings.txt`." I'm unsure if the behavior should be
 kept, but system checks aren't executed when running Django through
 `wsgi.py` rather than through `runserver`.

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

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

2016-12-27 Thread Django

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+-
 Reporter:  Ryan Schave  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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):

 * cc: Michael Manfre (added)
 * status:  new => closed
 * resolution:   => invalid


Comment:

 It looks like removing `supports_nullable_unique_constraints = False` may
 already yield a regression test in `tests/one_to_one/tests.py` due to the
 usage of the feature flag there. Maybe other backends like `django-mssql`
 would want to fix the issue so we could remove that feature?

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

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

2016-12-27 Thread Django

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+-
 Reporter:  Ryan Schave  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (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 Ryan Schave):

 It makes sense that the 3rd party backend should handle this.  There is
 already an open pull request (https://github.com/michiya/django-pyodbc-
 azure/pull/43) for django-pyodbc-azure.

 Would it be beneficial to submit the test that passes with the supported
 backends and fails with the the django-pyodbc-azure backend?  This would
 at least give visuality into the problem when Django tests are run against
 that backend.

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

Re: [Django] #27025: Python 3.6 compatibility

2016-12-27 Thread Django

#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

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


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

Re: [Django] #27025: Python 3.6 compatibility

2016-12-27 Thread Django

#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|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:"4701abd56e382bca72d4ff8e0b015948c9ab3feb" 4701abd5]:
 {{{
 #!CommitTicketReference repository=""
 revision="4701abd56e382bca72d4ff8e0b015948c9ab3feb"
 Refs #27025 -- Documented Python 3.6 compatibility for Django 1.11.
 }}}

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

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
> call on Python 3.5 and Python 3.6.
>
> The problem is apparently on this line:
>
> [https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290]
>
> Python documentation states that the ''`os.spawnve` function is NOT
> thread-safe on Windows'' and that the `subprocess` module should be used
> instead.
>
> I hence suspect that a thread that is spawned on reload makes a memory
> violation and causes a segmentation fault which kills off the server.
>
> I propose that `autoreload.py` be refactored to use a thread-safe
> implementation either by the subprocess module or by other alternative
> implementation.
>
> **Update**: I added a preliminary patch implementation up for review that
> implements a fix for Python 2.4+ in
> [https://github.com/django/django/pull/7748]  by using the recommended
> `subprocess.call()` instead of the non-thread-safe `os.spawnve()` which
> was added in a commit in 2005.
>
> 
>
> **Discussion**
>
> I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
> Windows 10 64-bit on different computers.  Starting with Python 3.5 and
> Python 3.6 I have reproduced a consistent segmentation fault on the
> `runserver` command with both 32-bit and 64-bit Pythons. This has
> happened for several months. `python manage.py migrate` and other
> commands work well and consistently. `python manage.py runserver` is the
> ONLY command that segmentation faults and does NOT do this with
> `--noreload` option. Today I dug a bit deeper on the cause of the
> segmentation fault.
>
> As a note, I have also run Django on top of Python 3.4 and at least the
> 32-bit distribution, for whatever reason, tends not to cause errors like
> these. This is, however, just my butt-feeling, as we say in Finland, and
> I have not measured the stuff for a small while.
>
> 
>
> **Demonstration**
>
> This example is run with `virtualenvwrapper` installed virtual
> environment with Python 3.6.0 32-bit with the latest available `Microsoft
> Visual C++ 2015 Redistributable (x86) - 14.0.23026` downloaded and
> patched today on Windows 10 64-bit, so I expect my computer is up to
> date. Program versions and tracebacks following.
>
> 
>
> **Python installation**
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ python
> Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
> bit (Intel)] on win32
> }}}
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ pip freeze  # global dependencies
> pbr==1.10.0
> six==1.10.0
> stevedore==1.19.1
> virtualenv==15.1.0
> virtualenv-clone==0.2.6
> virtualenvwrapper==4.7.2
> }}}
>
> 
>
> **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
> `wdupenv_s` as the evil party:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ gdb python
> GNU gdb (GDB) 7.6.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging
> symbols found)...done.
> (gdb) run manage.py runserver
> Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
> manage.py runserver
> [New Thread 6876.0x2a18]
> [New Thread 6876.0x13f4]
> [New Thread 6876.0x25d0]
> [New Thread 6876.0x2a64]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
> (gdb)
> }}}
>
> 
>
> **`faulthandler` traceback** with a vanilla `manage.py` script with
> `faulthandler` enabled with `faulthandler.enable()` which traces the
> D

Re: [Django] #27629: Inconsistent check of allow_relation in ForwardManyToOneDescriptor.set

2016-12-27 Thread Django

#27629: Inconsistent check of allow_relation in 
ForwardManyToOneDescriptor.__set__
-+-
 Reporter:  Sven Coenye  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  allow_relation   | Triage Stage:  Accepted
  ForwardManyToOneDescriptor |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sven Coenye):

 Perhaps a slightly overzealous optimization?

 To test further, I changed the two ForeignKey fields to point to models in
 a second application residing in the same database, and simplified
 allow_relation in the database router to:
 {{{
 def allow_relation(self, obj1, obj2, **hints):
 return False
 }}}
 The outcome remained the same. No errors are raised if only a single field
 links to an external model. If more fields are present, the first field
 gets a pass, the second field trips the ValueError exception.

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

Re: [Django] #27648: Deprecate ("iLmsu") regex groups in URLpatterns

2016-12-27 Thread Django

#27648: Deprecate ("iLmsu") regex groups in URLpatterns
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Aleksi Häkli:

Old description:

> Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
> call on Python 3.5 and Python 3.6.
>
> The problem is apparently on this line:
>
> https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290
>
> Python documentation states that the ''`os.spawnve` function is NOT
> thread-safe on Windows'' and that the `subprocess` module should be used
> instead.
>
> I hence suspect that a thread that is spawned on reload makes a memory
> violation and causes a segmentation fault which kills off the server.
>
> I propose that `autoreload.py` be refactored to use a thread-safe
> implementation either by the subprocess module or by other alternative
> implementation.
>
> **Update**: I added a preliminary patch implementation up for review that
> implements a fix for Python 2.4+ in
> [https://github.com/django/djangopull/7748]  by using the recommended
> `subprocess.call()` instead of the non-thread-safe `os.spawnve()` which
> was added in 2005.
>
> 
>
> **Discussion**
>
> I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
> Windows 10 64-bit on different computers.  Starting with Python 3.5 and
> Python 3.6 I have reproduced a consistent segmentation fault on the
> `runserver` command with both 32-bit and 64-bit Pythons. This has
> happened for several months. `python manage.py migrate` and other
> commands work well and consistently. `python manage.py runserver` is the
> ONLY command that segmentation faults and does NOT do this with
> `--noreload` option. Today I dug a bit deeper on the cause of the
> segmentation fault.
>
> As a note, I have also run Django on top of Python 3.4 and at least the
> 32-bit distribution, for whatever reason, tends not to cause errors like
> these. This is, however, just my butt-feeling, as we say in Finland, and
> I have not measured the stuff for a small while.
>
> 
>
> **Demonstration**
>
> This example is run with `virtualenvwrapper` installed virtual
> environment with Python 3.6.0 32-bit with the latest available `Microsoft
> Visual C++ 2015 Redistributable (x86) - 14.0.23026` downloaded and
> patched today on Windows 10 64-bit, so I expect my computer is up to
> date. Program versions and tracebacks following.
>
> 
>
> **Python installation**
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ python
> Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
> bit (Intel)] on win32
> }}}
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ pip freeze  # global dependencies
> pbr==1.10.0
> six==1.10.0
> stevedore==1.19.1
> virtualenv==15.1.0
> virtualenv-clone==0.2.6
> virtualenvwrapper==4.7.2
> }}}
>
> 
>
> **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
> `wdupenv_s` as the evil party:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ gdb python
> GNU gdb (GDB) 7.6.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging
> symbols found)...done.
> (gdb) run manage.py runserver
> Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
> manage.py runserver
> [New Thread 6876.0x2a18]
> [New Thread 6876.0x13f4]
> [New Thread 6876.0x25d0]
> [New Thread 6876.0x2a64]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
> (gdb)
> }}}
>
> 
>
> **`faulthandler` traceback** with a vanilla `manage.py` script with
> `faulthandler` enabled with `faulthandler.enable()

[Django] #27648: Deprecate ("iLmsu") regex groups in URLpatterns

2016-12-27 Thread Django

#27648: Deprecate ("iLmsu") regex groups in URLpatterns
-+-
Reporter: Tim| Owner: Tim Graham
Graham |
Type: | Status: assigned
Cleanup/optimization |
Component: Core |Version: master
(URLs) |
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 |
-+-
As [https://groups.google.com/d/topic/django-
developers/Y51CKkqq6Ng/discussion discussed on django-developers], Python
deprecated usage of flags not at the start of a regular expression, e.g.
'CaseInsensitive(?i)' instead of '(?i)CaseInsensitive'. A new solution
would be required to support these flags in Django, however, since case-
insensitive URLs aren't a good practice and the other flags don't have
value in urlpatterns, support for this will be removed. An alternative
solution for those wanting the functionality is to write a 404 handler to
look for uppercase characters and redirect to a lowercase equivalent.

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

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aleksi Häkli):

 * has_patch:  0 => 1


Old description:

> Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
> call on Python 3.5 and Python 3.6.
>
> The problem is apparently on this line:
>
> https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290
>
> Python documentation states that the ''`os.spawnve` function is NOT
> thread-safe on Windows'' and that the `subprocess` module should be used
> instead.
>
> I hence suspect that a thread that is spawned on reload makes a memory
> violation and causes a segmentation fault which kills off the server.
>
> I propose that `autoreload.py` be refactored to use a thread-safe
> implementation either by the subprocess module or by other alternative
> implementation.
>
> 
>
> **Discussion**
>
> I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
> Windows 10 64-bit on different computers.  Starting with Python 3.5 and
> Python 3.6 I have reproduced a consistent segmentation fault on the
> `runserver` command with both 32-bit and 64-bit Pythons. This has
> happened for several months. `python manage.py migrate` and other
> commands work well and consistently. `python manage.py runserver` is the
> ONLY command that segmentation faults and does NOT do this with
> `--noreload` option. Today I dug a bit deeper on the cause of the
> segmentation fault.
>
> As a note, I have also run Django on top of Python 3.4 and at least the
> 32-bit distribution, for whatever reason, tends not to cause errors like
> these. This is, however, just my butt-feeling, as we say in Finland, and
> I have not measured the stuff for a small while.
>
> 
>
> **Demonstration**
>
> This example is run with `virtualenvwrapper` installed virtual
> environment with Python 3.6.0 32-bit with the latest available `Microsoft
> Visual C++ 2015 Redistributable (x86) - 14.0.23026` downloaded and
> patched today on Windows 10 64-bit, so I expect my computer is up to
> date. Program versions and tracebacks following.
>
> 
>
> **Python installation**
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ python
> Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
> bit (Intel)] on win32
> }}}
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ pip freeze  # global dependencies
> pbr==1.10.0
> six==1.10.0
> stevedore==1.19.1
> virtualenv==15.1.0
> virtualenv-clone==0.2.6
> virtualenvwrapper==4.7.2
> }}}
>
> 
>
> **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
> `wdupenv_s` as the evil party:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ gdb python
> GNU gdb (GDB) 7.6.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging
> symbols found)...done.
> (gdb) run manage.py runserver
> Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
> manage.py runserver
> [New Thread 6876.0x2a18]
> [New Thread 6876.0x13f4]
> [New Thread 6876.0x25d0]
> [New Thread 6876.0x2a64]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
> (gdb)
> }}}
>
> 
>
> **`faulthandler` traceback** with a vanilla `manage.py` script with
> `faulthandler` enabled with `faulthandler.enable()` which traces the
> Django error back to `autoreload.py`:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ python manage.py runserver
>
> Windows fatal exception: access violation
>
> Current thread 0x1b6c (most recent call first):
>

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

2016-12-27 Thread Django

#27627: OneToOneField doesn't allow multiple records with NULL value on 
Microsoft
SQL Server
-+-
 Reporter:  Ryan Schave  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Most likely -- look at the code of the backend you're using and see if it
 subclasses Django's base classes.

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

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
> call on Python 3.5 and Python 3.6.
>
> The problem is apparently on this line:
>
> https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290
>
> Python documentation states that the _`os.spawnve` function is NOT
> thread-safe on Windows_ and that the `subprocess` module should be used
> instead.
>
> I hence suspect that a thread that is spawned on reload makes a memory
> violation and causes a segmentation fault which kills off the server.
>
> I propose that `autoreload.py` be refactored to use a thread-safe
> implementation either by the subprocess module or by other alternative
> implementation.
>
> 
>
> **Discussion**
>
> I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
> Windows 10 64-bit on different computers.  Starting with Python 3.5 and
> Python 3.6 I have reproduced a consistent segmentation fault on the
> `runserver` command with both 32-bit and 64-bit Pythons. This has
> happened for several months. `python manage.py migrate` and other
> commands work well and consistently. `python manage.py runserver` is the
> ONLY command that segmentation faults and does NOT do this with
> `--noreload` option. Today I dug a bit deeper on the cause of the
> segmentation fault.
>
> As a note, I have also run Django on top of Python 3.4 and at least the
> 32-bit distribution, for whatever reason, tends not to cause errors like
> these. This is, however, just my butt-feeling, as we say in Finland, and
> I have not measured the stuff for a small while.
>
> 
>
> **Demonstration**
>
> This example is run with `virtualenvwrapper` installed virtual
> environment with Python 3.6.0 32-bit with the latest available `Microsoft
> Visual C++ 2015 Redistributable (x86) - 14.0.23026` downloaded and
> patched today on Windows 10 64-bit, so I expect my computer is up to
> date. Program versions and tracebacks following.
>
> 
>
> **Python installation**
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ python
> Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
> bit (Intel)] on win32
> }}}
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ pip freeze  # global dependencies
> pbr==1.10.0
> six==1.10.0
> stevedore==1.19.1
> virtualenv==15.1.0
> virtualenv-clone==0.2.6
> virtualenvwrapper==4.7.2
> }}}
>
> 
>
> **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
> `wdupenv_s` as the evil party:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ gdb python
> GNU gdb (GDB) 7.6.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging
> symbols found)...done.
> (gdb) run manage.py runserver
> Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
> manage.py runserver
> [New Thread 6876.0x2a18]
> [New Thread 6876.0x13f4]
> [New Thread 6876.0x25d0]
> [New Thread 6876.0x2a64]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
> (gdb)
> }}}
>
> 
>
> **`faulthandler` traceback** with a vanilla `manage.py` script with
> `faulthandler` enabled with `faulthandler.enable()` which traces the
> Django error back to `autoreload.py`:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ python manage.py runserver
>
> Windows fatal exception: access violation
>
> Current thread 0x1b6c (most recent call first):
>   File "C:\Users\USER\.virtualenvs\demo\lib\site-
>

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
> call on Python 3.5 and Python 3.6.
>
> The problem is apparently on this line:
>
> https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290
>
> 
>
> **Discussion**
>
> I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
> Windows 10 64-bit on different computers.  Starting with Python 3.5 and
> Python 3.6 I have reproduced a consistent segmentation fault on the
> `runserver` command with both 32-bit and 64-bit Pythons. This has
> happened for several months. `python manage.py migrate` and other
> commands work well and consistently. `python manage.py runserver` is the
> ONLY command that segmentation faults and does NOT do this with
> `--noreload` option. Today I dug a bit deeper on the cause of the
> segmentation fault.
>
> As a note, I have also run Django on top of Python 3.4 and at least the
> 32-bit distribution, for whatever reason, tends not to cause errors like
> these. This is, however, just my butt-feeling, as we say in Finland, and
> I have not measured the stuff for a small while.
>
> 
>
> **Demonstration**
>
> This example is run with `virtualenvwrapper` installed virtual
> environment with Python 3.6.0 32-bit with the latest available `Microsoft
> Visual C++ 2015 Redistributable (x86) - 14.0.23026` downloaded and
> patched today on Windows 10 64-bit, so I expect my computer is up to
> date. Program versions and tracebacks following.
>
> 
>
> **Python installation**
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ python
> Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
> bit (Intel)] on win32
> }}}
>
> {{{
> USER@COMPUTER MINGW32 ~
> $ pip freeze  # global dependencies
> pbr==1.10.0
> six==1.10.0
> stevedore==1.19.1
> virtualenv==15.1.0
> virtualenv-clone==0.2.6
> virtualenvwrapper==4.7.2
> }}}
>
> 
>
> **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
> `wdupenv_s` as the evil party:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ gdb python
> GNU gdb (GDB) 7.6.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32".
> For bug reporting instructions, please see:
> ...
> Reading symbols from
> C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging
> symbols found)...done.
> (gdb) run manage.py runserver
> Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
> manage.py runserver
> [New Thread 6876.0x2a18]
> [New Thread 6876.0x13f4]
> [New Thread 6876.0x25d0]
> [New Thread 6876.0x2a64]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
> (gdb)
> }}}
>
> 
>
> **`faulthandler` traceback** with a vanilla `manage.py` script with
> `faulthandler` enabled with `faulthandler.enable()` which traces the
> Django error back to `autoreload.py`:
>
> {{{
> (demo)
> USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
> $ python manage.py runserver
>
> Windows fatal exception: access violation
>
> Current thread 0x1b6c (most recent call first):
>   File "C:\Users\USER\.virtualenvs\demo\lib\site-
> packages\django\utils\autoreload.py", line 290 in restart_with_reloader
>   File "C:\Users\USER\.virtualenvs\demo\lib\site-
> packages\django\utils\autoreload.py", line 304 in python_reloader
>   File "C:\Users\USER\.virtualenvs\demo\lib\site-
> packages\django\utils\autoreload.py", line 333 in main
>   File "C:\Users\USER\.virtualenvs\demo\lib\site-
> packages\django\core\management\commands\runserver.py", line 106 in run
>   File "C:\Users\USER\.virtualenvs\

Re: [Django] #27627: OneToOneField doesn't allow multiple records with NULL value on Microsoft SQL Server

2016-12-27 Thread Django

Comment (by Ryan Schave):

I can produce a test that passes w/ SQLite and PostgreSQL, but fails with
MS SQL. I assume since MS SQL is not a built-in backend, there is little
that can be done easily on the Django side and my experience w/ MS
suggests they aren't going to address this. I created a custom migration
that removes the constraint added by the initial Django migration and add
a unique index that allows multiple NULLs.

I assume that the code in django/db/migrations works together with the
appropriate backend in django/db/backends. Does Django use the base
backend when a 3rd party database is used?

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

Re: [Django] #27637: timeuntil, timesince breaks in leap year edge case

2016-12-27 Thread Django

#27637: timeuntil, timesince breaks in leap year edge case
-+
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  timeuntil timesince  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"50830aa1d93a1a703a5c2c546f730c1afb3f4a0a" 50830aa1]:
 {{{
 #!CommitTicketReference repository=""
 revision="50830aa1d93a1a703a5c2c546f730c1afb3f4a0a"
 [1.9.x] Fixed #27637 -- Fixed timesince, timeuntil in leap year edge case.

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

Re: [Django] #27642: Make `forms.utils.flatatt` not add values which are `None` to attrs

2016-12-27 Thread Django

#27642: Make `forms.utils.flatatt` not add values which are `None` to attrs
-+-
 Reporter:  Illia Volochii   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  flatatt  | 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 ):

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


Comment:

 In [changeset:"4a51ba228b2c416a115aee3bc034683eb02482c3" 4a51ba2]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a51ba228b2c416a115aee3bc034683eb02482c3"
 Fixed #27642 -- Made forms.utils.flatatt() omit 'None' values from attrs.
 }}}

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

Re: [Django] #27637: timeuntil, timesince breaks in leap year edge case

2016-12-27 Thread Django

#27637: timeuntil, timesince breaks in leap year edge case
-+
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  timeuntil timesince  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"25e8222615f75e55673dd7a54aa50b77762b6f8c" 25e82226]:
 {{{
 #!CommitTicketReference repository=""
 revision="25e8222615f75e55673dd7a54aa50b77762b6f8c"
 [1.10.x] Fixed #27637 -- Fixed timesince, timeuntil in leap year edge
 case.

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

Re: [Django] #27647: Django runserver segfaults with autoreload enabled on Windows 10 (was: Django segmentation faults with server autoreload enabled on Windows 10)

2016-12-27 Thread Django

#27647: Django runserver segfaults with autoreload enabled on Windows 10
-+-
 Reporter:  Aleksi Häkli |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:
  autoreload autoreload.py noreload  |  Unreviewed
  restart_with_reloader segfault |
  segmentation fault ucrtbase.dll|
  threading  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Aleksi Häkli):

 More detailed title

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

[Django] #27647: Django segmentation faults with server autoreload enabled on Windows 10

2016-12-27 Thread Django

#27647: Django segmentation faults with server autoreload enabled on Windows 10
-+-
   Reporter:  Aleksi |  Owner:  nobody
  Häkli  |
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  1.10
  (Management commands)  |   Keywords:  runserver
   Severity:  Normal |  autoreload autoreload.py noreload
 |  restart_with_reloader segfault
 |  segmentation fault ucrtbase.dll
   Triage Stage: |  threading
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Django `runserver` segfaults with autoreload enabled on the `os.spawnve`
 call on Python 3.5 and Python 3.6.

 The problem is apparently on this line:

 
https://github.com/django/django/blob/b79fc11d730b5beff92e9dd8853a61524cdeffe3/django/utils/autoreload.py#L290

 

 **Discussion**

 I have run Django 1.8, 1.9 and 1.10 on multiple Python versions on top of
 Windows 10 64-bit on different computers.  Starting with Python 3.5 and
 Python 3.6 I have reproduced a consistent segmentation fault on the
 `runserver` command with both 32-bit and 64-bit Pythons. This has happened
 for several months. `python manage.py migrate` and other commands work
 well and consistently. `python manage.py runserver` is the ONLY command
 that segmentation faults and does NOT do this with `--noreload` option.
 Today I dug a bit deeper on the cause of the segmentation fault.

 As a note, I have also run Django on top of Python 3.4 and at least the
 32-bit distribution, for whatever reason, tends not to cause errors like
 these. This is, however, just my butt-feeling, as we say in Finland, and I
 have not measured the stuff for a small while.

 

 **Demonstration**

 This example is run with `virtualenvwrapper` installed virtual environment
 with Python 3.6.0 32-bit with the latest available `Microsoft Visual C++
 2015 Redistributable (x86) - 14.0.23026` downloaded and patched today on
 Windows 10 64-bit, so I expect my computer is up to date. Program versions
 and tracebacks following.

 

 **Python installation**

 {{{
 USER@COMPUTER MINGW32 ~
 $ python
 Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32
 bit (Intel)] on win32
 }}}

 {{{
 USER@COMPUTER MINGW32 ~
 $ pip freeze  # global dependencies
 pbr==1.10.0
 six==1.10.0
 stevedore==1.19.1
 virtualenv==15.1.0
 virtualenv-clone==0.2.6
 virtualenvwrapper==4.7.2
 }}}

 

 **`gdb` traceback** on the error which identifies `ucrtbase.dll` and
 `wdupenv_s` as the evil party:

 {{{
 (demo)
 USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
 $ gdb python
 GNU gdb (GDB) 7.6.1
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "mingw32".
 For bug reporting instructions, please see:
 ...
 Reading symbols from
 C:\Users\USER\.virtualenvs\demo\Scripts\python.exe...(no debugging symbols
 found)...done.
 (gdb) run manage.py runserver
 Starting program: C:\Users\USER\.virtualenvs\demo\Scripts/python.exe
 manage.py runserver
 [New Thread 6876.0x2a18]
 [New Thread 6876.0x13f4]
 [New Thread 6876.0x25d0]
 [New Thread 6876.0x2a64]

 Program received signal SIGSEGV, Segmentation fault.
 0x77cebd9e in wdupenv_s () from C:\WINDOWS\SysWoW64\ucrtbase.dll
 (gdb)
 }}}

 

 **`faulthandler` traceback** with a vanilla `manage.py` script with
 `faulthandler` enabled with `faulthandler.enable()` which traces the
 Django error back to `autoreload.py`:

 {{{
 (demo)
 USER@COMPUTER MINGW32 ~/Documents/projects/demo (master)
 $ python manage.py runserver

 Windows fatal exception: access violation

 Current thread 0x1b6c (most recent call first):
   File "C:\Users\USER\.virtualenvs\demo\lib\site-
 packages\django\utils\autoreload.py", line 290 in restart_with_reloader
   File "C:\Users\USER\.virtualenvs\demo\lib\site-
 packages\django\utils\autoreload.py", line 304 in python_reloader
   File "C:\Users\USER\.virtualenvs\demo\lib\site-
 packages\django\utils\autoreload.py", line 333 in main
   File "C:\Users\USER\.virtualenvs\demo\lib\site-
 packages\django\core\management\commands\runserver.py", line 106 in run
   File "C:\Users\USER\.virtualenvs\demo\lib\site-
 packages\django\core\management\commands\runserver.py", line

Re: [Django] #27637: timeuntil, timesince breaks in leap year edge case

2016-12-27 Thread Django

#27637: timeuntil, timesince breaks in leap year edge case
-+
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.9
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  timeuntil timesince  | 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 ):

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


Comment:

 In [changeset:"3e5c5e6754648590e87725b66d11d283079728e6" 3e5c5e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="3e5c5e6754648590e87725b66d11d283079728e6"
 Fixed #27637 -- Fixed timesince, timeuntil in leap year edge 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/065.5395d22f093d56a325f4366a69aac68a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27646: Add QuerySet support for group by modifiers and OLAP functionality (was: Group by modifiers, OLAP functionality)

2016-12-27 Thread Django

#27646: Add QuerySet support for group by modifiers and OLAP functionality
-+-
 Reporter:  Mads Jensen  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  olap rollup orm  | 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


Comment:

 Tentatively accepting. It might be nice to elaborate on the details such
 as by writing documentation and getting feedback on that before starting
 to code.

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

Re: [Django] #27644: Document FileSystemStorage.get_created_time() limitation on Unix (was: FileSystemStorage --- get_created_time method does not work on Unix)

2016-12-27 Thread Django

#27644: Document FileSystemStorage.get_created_time() limitation on Unix
--+
 Reporter:  Jonathan Verner   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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):

 * component:  File uploads/storage => Documentation
 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization


Comment:

 Accepting as a documentation clarification for now. I'm not sure if
 changing the method's implementation is worth it, but I think it would
 require a deprecation path. If you want to pursue that, please raise the
 idea on the DevelopersMailingList to get a consensus.

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

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

Re: [Django] #27641: Document limitations of the Locmem cache backend (was: Default CACHES uses Locmem which isn't suitable for production)

2016-12-27 Thread Django

#27641: Document limitations of the Locmem cache backend
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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):

 * component:  Core (Cache system) => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Some limitations are already documented in
 [https://docs.djangoproject.com/en/stable/topics/cache/#local-memory-
 caching Local-memory caching].

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

Re: [Django] #27638: Rollback data changes made inside templates

2016-12-27 Thread Django

#27638: Rollback data changes made inside templates
-+-
 Reporter:  vinay karanam|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinay karanam):

 I've sent a [https://github.com/django/django/pull/7747 PR] with initial
 draft.

 All the testcases are passing except for `StartProject`.
 Any suggestions in dealing with that.

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

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

[Django] #27646: Group by modifiers, OLAP functionality

2016-12-27 Thread Django

#27646: Group by modifiers, OLAP functionality
-+-
Reporter: Mads | Owner: nobody
Jensen |
Type: New| Status: new
feature|
Component: Database |Version: master
layer (models, ORM)|
Severity: Normal | Keywords: olap rollup orm
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
PostgreSQL 9.5 introduced `cube`, `grouping sets` and `rollup`.
MySQL/MariaDB supports the `rollup`-operation for aggregations. Oracle
(obviously) also supports `rollup`, `grouping sets` and `cube`. I suggest
adding methods in `QuerySet` for this, feature-flags to indicate level of
support, and either new expressions for the different `rollup`-syntax, or
amend the operations of the backends for this. The syntax is slightly
different in MySQL/MariaDB, as it uses `WITH ROLLUP`, rather than
`ROLLUP`.

https://oracle-base.com/articles/misc/rollup-cube-grouping-functions-and-
grouping-sets
http://dev.mysql.com/doc/refman/5.7/en/group-by-modifiers.html
https://www.postgresql.org/docs/current/static/queries-table-
expressions.html#QUERIES-GROUPING-SETS

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

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

Re: [Django] #27642: Make `forms.utils.flatatt` not add values which are `None` to attrs

2016-12-27 Thread Django

#27642: Make `forms.utils.flatatt` not add values which are `None` to attrs
-+-
 Reporter:  Illia Volochii   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  flatatt  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #27645: Move Settings.init checks to system checks

2016-12-27 Thread Django

#27645: Move Settings.__init__ checks to system checks
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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


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

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

Re: [Django] #27644: FileSystemStorage --- get_created_time method does not work on Unix

2016-12-27 Thread Django

#27644: FileSystemStorage --- get_created_time method does not work on Unix
-+-
 Reporter:  Jonathan Verner  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.10
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jonathan Verner):

 Replying to [comment:1 Adam Chainz]:
 > Perhaps `ctime` is good enough though, making the presumption that the
 inode attributes only change at creation time?

 Unfortunately, that is not the case: `ctime` changes at least as often as
 `mtime` does---updating the `mtime` changes inode attributes.

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

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

Re: [Django] #27641: Default CACHES uses Locmem which isn't suitable for production

2016-12-27 Thread Django

Comment (by Aymeric Augustin):

> The way Django uses caching is to assume there's a single cache for the
whole application

This is correct, hovewer, considering the contract of Django cache
backends -- keys can be evicted arbitrarily -- I believe that in (most)
(reasonable) cases the effect of separate workers using separate caches is
lower performance (cache hits / N for N workers) and increased resource
usage (memory * N for N workers). This is annoying but not always worth
the effort of setting up or paying for a separate cache server. I have
used the locmem cache successfully in production for modest optimizations
such as template caching.

I'd rather handle this in the documentation.

One surprising and little know characteristic of the locmem cache backend
is that it's bounded to 300 keys by default. Even for caching medium-size
objects (let's say 8kB), that's quite low (limited to 2,4MB). I'm not sure
the docs mention it sufficiently clearly. If we explain the downsides of
using the locmem cache in production, it would be a good place to mention
that this setting likely needs tuning.

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

Re: [Django] #27641: Default CACHES uses Locmem which isn't suitable for production

2016-12-27 Thread Django

#27641: Default CACHES uses Locmem which isn't suitable for production
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 Type:   |  Chainz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  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
-+-

Comment (by Claude Paroz):

 I do agree with Tim. I'm deploying many small single-process apps using
 Apache/mod_wsgi and I *think* using locmem cache is fine (even if I'm
 using memcache in several of these instances).

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

41 matches

Mail list logo