Re: [Django] #28160: Prevent hiding GDAL errors if it's not installed

[Django]

#28160: Prevent hiding GDAL errors if it's not installed
-+-
 Reporter:  Tom Kazimiers|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  GIS, GDAL, Contrib,  | Triage Stage:  Accepted
  Bug|
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:"68ebc240a47cb235a186a01f887db318e0a55eba" 68ebc24]:
 {{{
 #!CommitTicketReference repository=""
 revision="68ebc240a47cb235a186a01f887db318e0a55eba"
 [1.11.x] Fixed #28160 -- Prevented hiding GDAL exceptions when it's not
 installed.

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

Re: [Django] #28160: Prevent hiding GDAL errors if it's not installed

[Django]

#28160: Prevent hiding GDAL errors if it's not installed
-+-
 Reporter:  Tom Kazimiers|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  GIS, GDAL, Contrib,  | Triage Stage:  Accepted
  Bug|
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:"2dc3280254ae06ca1fe664abf55749fe12a699d4" 2dc3280]:
 {{{
 #!CommitTicketReference repository=""
 revision="2dc3280254ae06ca1fe664abf55749fe12a699d4"
 Fixed #28160 -- Prevented hiding GDAL exceptions when it's not 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/063.5b37aee445b28ce06ec812adb2633389%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28160: Prevent hiding GDAL errors if it's not installed

[Django]

#28160: Prevent hiding GDAL errors if it's not installed
-+-
 Reporter:  Tom Kazimiers|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GDAL, Contrib,  | Triage Stage:  Accepted
  Bug|
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:"444cdf61314e420c10f713ba7a5fa084b0b2dfd5" 444cdf6]:
 {{{
 #!CommitTicketReference repository=""
 revision="444cdf61314e420c10f713ba7a5fa084b0b2dfd5"
 [1.11.x] Made runtests.py run gis_tests only when using a GIS database
 backend.

 This facilitates other changes like refs #28160.

 Backport of 890537253cf235091816d27a5c2fb64943c8e34a 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/063.b1c01a90f208e7754600875291f9ade1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28160: Prevent hiding GDAL errors if it's not installed

[Django]

#28160: Prevent hiding GDAL errors if it's not installed
-+-
 Reporter:  Tom Kazimiers|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GDAL, Contrib,  | Triage Stage:  Accepted
  Bug|
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:"890537253cf235091816d27a5c2fb64943c8e34a" 89053725]:
 {{{
 #!CommitTicketReference repository=""
 revision="890537253cf235091816d27a5c2fb64943c8e34a"
 Made runtests.py run gis_tests only when using a GIS database backend.

 This facilitates other changes like refs #28160.
 }}}

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

Re: [Django] #28174: Cannot run `manage.py runserver` on Windows with quotation mark in .env file (TypeError: environment can only contain strings)

[Django]

#28174: Cannot run `manage.py runserver` on Windows with quotation mark in .env
file (TypeError: environment can only contain strings)
-+-
 Reporter:  Paul Mestemaker  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.11
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Could you please
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisect] to determine the Django commit
 where the behavior changed? Please also provide steps to reproduce the
 issue and explain why Django is at fault.

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

[Django] #28174: Cannot run `manage.py runserver` on Windows with quotation mark in .env file (TypeError: environment can only contain strings)

[Django]

#28174: Cannot run `manage.py runserver` on Windows with quotation mark in .env
file (TypeError: environment can only contain strings)
-+-
   Reporter:  Paul   |  Owner:  nobody
  Mestemaker |
   Type:  Bug| Status:  new
  Component:  Core   |Version:  1.11
  (Management commands)  |
   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  |
-+-
 We have a .env file with a SECRET_KEY defined as follows
 SECRET_KEY="SECRETKEYHERE"

 This causes a failure with Django 1.11. The workarounds are:
 1) Downgrade to Django 1.10
 2) Remove the quotation marks and just have SECRET_KEY=SECRETKEYHERE

 This appears to only be a problem on Windows and does not repro on
 Mac/Linux.

 {{{
 (tmadashboard) c:\development\workspaces\tma\dashboard\dashboard>pip
 install django==1.10 --upgrade
 Collecting django==1.10
   Downloading Django-1.10-py2.py3-none-any.whl (6.8MB)
 100% || 6.8MB 124kB/s
 Installing collected packages: django
   Found existing installation: Django 1.11
 Uninstalling Django-1.11:
   Successfully uninstalled Django-1.11
 Successfully installed django-1.10

 (tmadashboard) c:\development\workspaces\tma\dashboard\dashboard>python
 manage.py runserver
 Performing system checks...

 RUNNING IN DEVELOPMENT MODE. ADDING STATIC FILE DIRECTORIES TO SERVE
 System check identified no issues (0 silenced).
 May 04, 2017 - 12:46:16
 Django version 1.10, using settings 'dashboard.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.

 (tmadashboard) c:\development\workspaces\tma\dashboard\dashboard>pip
 install --upgrade django
 Collecting django
   Using cached Django-1.11-py2.py3-none-any.whl
 Requirement already up-to-date: pytz in
 c:\development\python\python2712\virtualenvs\tmadashboard\lib\site-
 packages (from django)
 Installing collected packages: django
   Found existing installation: Django 1.10
 Uninstalling Django-1.10:
   Successfully uninstalled Django-1.10
 Successfully installed django-1.11

 (tmadashboard) c:\development\workspaces\tma\dashboard\dashboard>python
 manage.py runserver
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\__init__.py", line 363, in
 execute_from_command_line
 utility.execute()
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\__init__.py", line 355, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\base.py", line 283, in run_from_argv
 self.execute(*args, **cmd_options)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\commands\runserver.py", line 62, in
 execute
 super(Command, self).execute(*args, **options)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\base.py", line 330, in execute
 output = self.handle(*args, **options)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\commands\runserver.py", line 101, in
 handle
 self.run(**options)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\core\management\commands\runserver.py", line 110, in
 run
 autoreload.main(self.inner_run, None, options)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\utils\autoreload.py", line 332, in main
 reloader(wrapped_main_func, args, kwargs)
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\utils\autoreload.py", line 303, in python_reloader
 exit_code = restart_with_reloader()
   File "c:\development\python\Python2712\virtualenvs\tmadashboard\lib
 \site-packages\django\utils\autoreload.py", line 289, in
 restart_with_reloader
 exit_code = subprocess.call(args, env=new_environ)
   File "c:\development\python\python2712\Lib\subprocess.py", line 523, in
 call
 return Popen(*popenargs, **kwargs).wait()
   File "c:\development\python\python2712\Lib\subprocess.py", line 711, in
 __init__
 errread, errwrite)
   File "c:\development\python\python2712\Lib\subprocess.py", line 959, in
 

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

[Django]

#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
-+-
 Reporter:  David Szotten|Owner:  Romain
 |  Garrigues
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan P Kilby):

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

Re: [Django] #28173: Occasional FieldError for field that really does exist

[Django]

#28173: Occasional FieldError for field that really does exist
-+-
 Reporter:  Evan Heidtmann   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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:   => invalid
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => Bug


Comment:

 Please see TicketClosingReasons/UseSupportChannels for ways to get help.
 The discussion in #27365 may help you.

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

Re: [Django] #28173: Occasional FieldError for field that really does exist

[Django]

#28173: Occasional FieldError for field that really does exist
+--
 Reporter:  Evan Heidtmann  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Evan Heidtmann:

Old description:

> My app, running in production with `uwsgi`, very occasionally will crash
> because of a FieldError on a (valid) reverse ForeignKey relationship
> field. Without any code changes, other requests will succeed. Tests that
> cover this code path always pass.
>
> The two models are in different apps. Both apps are listed in
> `INSTALLED_APPS` and the calling module imports both `models` modules at
> top level. One of the models is "replaceable" but I'm using the original
> model (it's oauth2_provider.Application)
>
> {{{#!python
> # app1/models.py
> class A(models.Model):
> name = models.CharField(max_length=20)
>
> def get_A_model():
> # ... some thirdparty code for replaceable models ...
>
> # app2/models.py
> class B(models.Model):
> myname = models.CharField(max_length=20)
> a = models.ForeignKey('app1.A')
>
> # app2/views.py
> import app1.models as app1_models
> from . import models
>
> def view(request):
># This line crashes with "FieldError: Cannot resolve keyword 'b' into
> field. Choices are: ..."
> qs = get_A_model().objects.filter(b__myname='larry')
> }}}
>

> This smells like some kind of deployment issue (code loading too late or
> not at all?) but if so, I don't know how to debug. Thanks for taking a
> look and let me know what I can do to gather more helpful information.

New description:

 My app, running in production with `uwsgi`, very occasionally will crash
 because of a FieldError on a (valid) reverse ForeignKey relationship
 field. Without any code changes, other requests will succeed. Tests that
 cover this code path always pass.

 The two models are in different apps. Both apps are listed in
 `INSTALLED_APPS` and the calling module imports both `models` modules at
 top level. One of the models is "replaceable" but I'm using the original
 model (it's oauth2_provider.Application)

 {{{#!python
 # app1/models.py
 class A(models.Model):
 name = models.CharField(max_length=20)

 def get_A_model():
 # ... some thirdparty code for replaceable models ...

 # app2/models.py
 class B(models.Model):
 myname = models.CharField(max_length=20)
 a = models.ForeignKey('app1.A')

 # app2/views.py
 import app1.models as app1_models
 from . import models

 def view(request):
# This line crashes with "FieldError: Cannot resolve keyword 'b' into
 field. Choices are: ..."
 qs = app1_models.get_A_model().objects.filter(b__myname='larry')
 }}}


 This smells like some kind of deployment issue (code loading too late or
 not at all?) but if so, I don't know how to debug. Thanks for taking a
 look and let me know what I can do to gather more helpful information.

--

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

Re: [Django] #28173: Occasional FieldError for field that really does exist

[Django]

#28173: Occasional FieldError for field that really does exist
+--
 Reporter:  Evan Heidtmann  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.9
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Evan Heidtmann:

Old description:

> My app, running in production with `uwsgi`, very occasionally will crash
> because of a FieldError on a (valid) reverse ForeignKey relationship
> field. Without any code changes, other requests will succeed. Tests that
> cover this code path always pass.
>
> The two models are in different apps. Both apps are listed in
> `INSTALLED_APPS` and the calling module imports both `models` modules at
> top level. One of the models is "replaceable" but I'm using the original
> model (it's oauth2_provider.Application)
>
> ```
> # app1/models.py
> class A(models.Model):
> name = models.CharField(max_length=20)
>
> def get_A_model():
> # ... some thirdparty code for replaceable models ...
>
> # app2/models.py
> class B(models.Model):
> myname = models.CharField(max_length=20)
> a = models.ForeignKey('app1.A')
>
> # app2/views.py
> import app1.models as app1_models
> from . import models
>
> def view(request):
># This line crashes with "FieldError: Cannot resolve keyword 'b' into
> field. Choices are: ..."
> qs = get_A_model().objects.filter(b__myname='larry')
> ```
>

> This smells like some kind of deployment issue (code loading too late or
> not at all?) but if so, I don't know how to debug. Thanks for taking a
> look and let me know what I can do to gather more helpful information.

New description:

 My app, running in production with `uwsgi`, very occasionally will crash
 because of a FieldError on a (valid) reverse ForeignKey relationship
 field. Without any code changes, other requests will succeed. Tests that
 cover this code path always pass.

 The two models are in different apps. Both apps are listed in
 `INSTALLED_APPS` and the calling module imports both `models` modules at
 top level. One of the models is "replaceable" but I'm using the original
 model (it's oauth2_provider.Application)

 {{{#!python
 # app1/models.py
 class A(models.Model):
 name = models.CharField(max_length=20)

 def get_A_model():
 # ... some thirdparty code for replaceable models ...

 # app2/models.py
 class B(models.Model):
 myname = models.CharField(max_length=20)
 a = models.ForeignKey('app1.A')

 # app2/views.py
 import app1.models as app1_models
 from . import models

 def view(request):
# This line crashes with "FieldError: Cannot resolve keyword 'b' into
 field. Choices are: ..."
 qs = get_A_model().objects.filter(b__myname='larry')
 }}}


 This smells like some kind of deployment issue (code loading too late or
 not at all?) but if so, I don't know how to debug. Thanks for taking a
 look and let me know what I can do to gather more helpful information.

--

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

[Django] #28173: Occasional FieldError for field that really does exist

[Django]

#28173: Occasional FieldError for field that really does exist
--+
   Reporter:  Evan Heidtmann  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  1.9
   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   |
--+
 My app, running in production with `uwsgi`, very occasionally will crash
 because of a FieldError on a (valid) reverse ForeignKey relationship
 field. Without any code changes, other requests will succeed. Tests that
 cover this code path always pass.

 The two models are in different apps. Both apps are listed in
 `INSTALLED_APPS` and the calling module imports both `models` modules at
 top level. One of the models is "replaceable" but I'm using the original
 model (it's oauth2_provider.Application)

 ```
 # app1/models.py
 class A(models.Model):
 name = models.CharField(max_length=20)

 def get_A_model():
 # ... some thirdparty code for replaceable models ...

 # app2/models.py
 class B(models.Model):
 myname = models.CharField(max_length=20)
 a = models.ForeignKey('app1.A')

 # app2/views.py
 import app1.models as app1_models
 from . import models

 def view(request):
# This line crashes with "FieldError: Cannot resolve keyword 'b' into
 field. Choices are: ..."
 qs = get_A_model().objects.filter(b__myname='larry')
 ```


 This smells like some kind of deployment issue (code loading too late or
 not at all?) but if so, I don't know how to debug. Thanks for taking a
 look and let me know what I can do to gather more helpful information.

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

Re: [Django] #28160: Prevent hiding GDAL errors if it's not installed (was: Prevent hiding GDAL errors)

[Django]

#28160: Prevent hiding GDAL errors if it's not installed
-+-
 Reporter:  Tom Kazimiers|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  GIS, GDAL, Contrib,  | Triage Stage:  Accepted
  Bug|
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


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

[Django] #28172: Non-existent arg passed to template filter raises VariableDoesNotExist (alternative solution)

[Django]

#28172: Non-existent arg passed to template filter raises VariableDoesNotExist
(alternative solution)
---+
   Reporter:  Vlastimil Zíma   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  master
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I'd like to fix the error reported in #13167. The main bug

 {{{
 #!python
 from django.template import Context, Template
 Template('{{ foo|default:notreal }}').render(Context({'foo': ''}))
 }}}

 still raises `VariableDoesNotExist` exception, which is completely
 unexpected from templates, as noted in closing comment
 ticket:13167#comment:20. I took me more than an hour before I found out
 how did it make the server error I investigated.

 I know the original ticket was closed as wontfix, but I understood it was
 due to the effect the proposed change would have on `if` tag. But there's
 another way - capture the exception in `VariableNode` the similar way
 `UnicodeDecodeError` is silenced. If I understood the code correctly, that
 would solve the problem for all template filters, but left template tags
 intact.

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

Re: [Django] #27554: Queryset evaluation fails with mix of nested and flattened prefetches (AttributeError on RelatedManager)

[Django]

#27554: Queryset evaluation fails with mix of nested and flattened prefetches
(AttributeError on RelatedManager)
-+-
 Reporter:  Anthony Leontiev |Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  prefetch | Triage Stage:  Ready for
  AttributeError prefetch_related|  checkin
  nested RelatedManager  |
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:"c679ac04499798e366ca594f97e4f95d3da3682f" c679ac04]:
 {{{
 #!CommitTicketReference repository=""
 revision="c679ac04499798e366ca594f97e4f95d3da3682f"
 [1.11.x] Fixed #27554 -- Fixed prefetch_related() crash when fetching
 relations in nested Prefetches.

 Backport of c0a2b9508aa2c6eaa22e9787010276edca887f0b from master
 }}}

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

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

Re: [Django] #27554: Queryset evaluation fails with mix of nested and flattened prefetches (AttributeError on RelatedManager)

[Django]

#27554: Queryset evaluation fails with mix of nested and flattened prefetches
(AttributeError on RelatedManager)
-+-
 Reporter:  Anthony Leontiev |Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  prefetch | Triage Stage:  Ready for
  AttributeError prefetch_related|  checkin
  nested RelatedManager  |
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:"c0a2b9508aa2c6eaa22e9787010276edca887f0b" c0a2b950]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0a2b9508aa2c6eaa22e9787010276edca887f0b"
 Fixed #27554 -- Fixed prefetch_related() crash when fetching relations in
 nested Prefetches.
 }}}

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

Re: [Django] #25546: Duplicate queries on nested Prefetch objects with custom queries

[Django]

#25546: Duplicate queries on nested Prefetch objects with custom queries
-+-
 Reporter:  Benjamin Wohlwend|Owner:  François
 Type:   |  Freitag
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch,| Triage Stage:  Ready for
  prefetch_related   |  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:"ec05ff086c0349e50c71b63c940a00a1d3f0385a" ec05ff08]:
 {{{
 #!CommitTicketReference repository=""
 revision="ec05ff086c0349e50c71b63c940a00a1d3f0385a"
 Refs #25546 -- Added detailed comments for prefetch_related test.
 }}}

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

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

[Django] #28171: empty_permitted=True contradicts use_required_attribute=True

[Django]

#28171: empty_permitted=True contradicts use_required_attribute=True
--+
   Reporter:  Vlastimil Zíma  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 It is possible to easily create a form which does not provide expected
 behavior. If a form is created with `empty_permitted=True`, it still
 renders a required attribute into its inputs, although it clearly
 shouldn't.

 {{{
 #!python
 from django import forms

 class FooForm(forms.Form):
  foo = forms.CharField()

 unicode(FooForm(empty_permitted=True))
 >>> u'Foo:'
 }}}

 I suggest to disable `use_required_attribute` if `empty_permitted` is
 enabled and/or raise exception if both attributes are set up
 contradictory. Even though `empty_permitted` is not a documented
 attribute, incorrect usage should be limited if possible.

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