Re: [Django] #901: [patch] Reload method for models

[Django]

#901: [patch] Reload method for models
-+-
 Reporter:  andreas@…|Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by simon29):

 Eric makes an important point. I gave up a long time ago trying to make
 simple feature suggestions like these, no matter how big/small (6yrs ago
 by the look of this thread).

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19866: SuspiciousOperation should not be answered with HTTP 500

[Django]

#19866: SuspiciousOperation should not be answered with HTTP 500
-+
 Reporter:  tiwoc|Owner:  ptone
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by ptone):

 One of the problematic things about the use of SuspiciousOperation, is
 that there is no way to get any specificity of event types.  If you care
 about some more than others, it you're stuck with parsing strings.

 Since we only raise this exception in relatively few places (I think I
 count 8), one idea would be to subclass SuspiciousOperation for each case,
 and have the logger put in e.__name__ at the beginning of the message, so
 there would at least be that.

 If we accept Alex's premise that logging should be bifurcated, into mild
 or oh-crap, which should SuspiciousOperation be.

 My inclination is to log SuspiciousOperation events as info/warning (I'd
 group those all below Error) and have people configure logging as needed.

 This does result in a change in behavior that should be strongly called
 out in the release notes, as any  suspicious operations in <=1.5 would be
 logged to monitoring tools that watch for 500s (ie sentry) and if we
 introduce a 400 response path that handles these exceptions, a new shim
 like the 404 middleware for raven will be needed to deliver these to
 sentry as well.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20384: GeoIP doesn't support unicode path

[Django]

#20384: GeoIP doesn't support unicode path
+---
 Reporter:  julian@…|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  GIS |Version:  1.5
 Severity:  Normal  |   Keywords:  geoip unicode
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 If the path that GeoIP should use is a unicode object it will fail to
 properly parse/identify the GeoIP databases.

 {{{
 >>> from django.contrib.gis.geoip import GeoIP
 >>> g = GeoIP(path='/path/to/GeoIP')
 >>> g.info
 'GeoIP Library:\n\t1.4.8\nCountry:\n\tGEO-106FREE [...]\nCity:\n\tGEO-
 533LITE [...]'
 >>> g = GeoIP(path=u'/path/to/GeoIP')
 >>> g.info
 'GeoIP Library:\n\t1.4.8\nCountry:\n\t\nCity:\n\t'
 }}}

 Tested this on Python 2.7. The same effect occurs in py3k, but getting it
 to work there in the same way would require using byte literals in
 {{{django/contrib/gis/geoip/base.py", line 92, in __init__}}}.


 Using Linux kernel 3.8.5-1-ARCH, ext4 filesystem and Python 2.7.4.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20025: Do something for MySQL under Python 3

[Django]

#20025: Do something for MySQL under Python 3
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by travis.jensen@…):

 Is there any chance of this getting into 1.5.2?  I realize I can play with
 it on master (and I'll probably start there), but I will have an easier
 time experimenting with it at work if I can say I'm playing with an
 official release. More experimenting from me means the test coverage for
 Django (ok, so maybe not enough to be worth it, but it doesn't hurt to ask
 :).

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20383: Makemessages must deal with context translations for a limited set of contexts.

[Django]

#20383: Makemessages must deal with context translations for a limited set of
contexts.
---+
 Reporter:  Filipe Waitman   |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Translations   |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi everyone.


 Django `makemessages` works fine when you define categorically a context
 to be used as a string, like

 {{{
 translated_message = pgettext('my_context', 'Hello World!')
 }}}


 But it can not "guess" your context when it's a variable (fair enough -
 when you have a variable with infinite possible values), like:

 {{{
 translated_message = pgettext(my_context_var, 'Hello World!')
 }}}


 However, I am working in a project that we have a limited set of contexts
 (in a white-label software where each context is a brand).
 Given it is a limited set of contexts I think Django can understand this
 and generate translation messages with each one of these contexts.


 Use case example: I have basically 3 values for contexts (for instance:
 "AAA", "BBB" and "CCC").
 Sometimes, I have to use things like

 {{{
 translated_message = pgettext(CURRENT_CONTEXT, 'Hello World!')
 }}}

 Would be great if when Django `makemessages` find a variable as the
 context, it generated one message for each possible context, as follows:

 {{{
 msgctxt "AAA"
 msgid "Hello World!"
 msgstr ""

 msgctxt "BBB"
 msgid "Hello World!"
 msgstr ""

 msgctxt "CCC"
 msgid "Hello World!"
 msgstr ""
 }}}

 The list of possible context to be used could be configured in the
 settings file, as follows:

 {{{
 # settings.py
 TRANSLATION_CONTEXTS = (
 'AAA',
 'BBB',
 'CCC',
 )
 }}}

 Does anyone else think this is a good feature to be added? Any predicted
 backwards incompatibility?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9a3708: Fixed a test that fails under Python 3.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9a3708cec8cf76165afd0fd46d1267d7cae772ca
  
https://github.com/django/django/commit/9a3708cec8cf76165afd0fd46d1267d7cae772ca
  Author: Aymeric Augustin 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M tests/model_forms_regress/tests.py

  Log Message:
  ---
  Fixed a test that fails under Python 3.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #901: [patch] Reload method for models

[Django]

#901: [patch] Reload method for models
-+-
 Reporter:  andreas@…|Owner:  adrian
 Type:  enhancement  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 So I just came across the presentation "Why Django Sucks and How we Can
 Fix it" at http://blip.tv/djangocon/why-django-sucks-and-how-we-can-fix-
 it-4131303

 As I watched it, this bug immediately came to mind.  I feel it is a
 perfect example of exactly what Eric was talking about in his talk.

 There are multiple StackOverflow questions asking how to do this, there
 are several answers there on how to do this, none of which are ensured to
 keep future compatibility.  Some are stated as incomplete  ("Oh, this
 won't work if you have foreign keys"), and potentially have other quirks.
 And there is no documented way that suggests the best/supported way to do
 this.

 There's a suggested patch above.

 Note:  The use case for this request isn't:

 obj = Foo.objects.get(pk=1)
 
 obj = obj.reload()   # i.e., obj = Foo.objects.get(pk=obj.id)

 It is people wanting to do a reload from *within* the model.  And "self =
 self.objects.get(pk=self.id)" isn't going to do it, obviously!

 The use case is more like:

   class Foo(Model):
 def blah():
   # maybe we need to use .update() for some reason, like
   # atomicity.  i.e., only update iff x is 0 as a atomicity
   # check.
   Foo.objects.filter(pk=self.id, x=0).update(x=1, y=10)
   
   # make sure I have the latest attributes
   self.reload()
   ...

 I don't want the client of the Model Foo to have to know "Oh, well, I need
 to refresh my copy of the object after I call blah()".   And other
 references to the object that called blah() will still be wrong.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19733: Deprecate ModelForm without explicit fields

[Django]

#19733: Deprecate ModelForm without explicit fields
-+-
 Reporter:  aaugustin|Owner:  lukeplant
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Forms|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Luke Plant ):

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


Comment:

 In [changeset:"f026a519aea8f3ea7ca339bfbbb007e1ee0068b0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f026a519aea8f3ea7ca339bfbbb007e1ee0068b0"
 Fixed #19733 - deprecated ModelForms without 'fields' or 'exclude', and
 added '__all__' shortcut

 This also updates all dependent functionality, including modelform_factory
  and modelformset_factory, and the generic views `ModelFormMixin`,
  `CreateView` and `UpdateView` which gain a new `fields` attribute.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 1e37cb: Further removal of static admin validation that ca...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1e37cb37cec330a6b78925e2ef5589817428d09a
  
https://github.com/django/django/commit/1e37cb37cec330a6b78925e2ef5589817428d09a
  Author: Luke Plant 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M django/contrib/admin/validation.py
M tests/admin_validation/tests.py
M tests/modeladmin/tests.py

  Log Message:
  ---
  Further removal of static admin validation that can fail erroneously


  Commit: f026a519aea8f3ea7ca339bfbbb007e1ee0068b0
  
https://github.com/django/django/commit/f026a519aea8f3ea7ca339bfbbb007e1ee0068b0
  Author: Luke Plant 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M django/contrib/admin/options.py
M django/contrib/auth/forms.py
M django/contrib/contenttypes/generic.py
M django/contrib/flatpages/forms.py
M django/contrib/formtools/tests/wizard/test_forms.py
M django/contrib/formtools/tests/wizard/wizardtests/tests.py
M django/forms/models.py
M django/views/generic/edit.py
M docs/ref/class-based-views/generic-editing.txt
M docs/ref/class-based-views/mixins-editing.txt
M docs/ref/contrib/admin/index.txt
M docs/ref/forms/models.txt
M docs/releases/1.6.txt
M docs/topics/auth/customizing.txt
M docs/topics/class-based-views/generic-editing.txt
M docs/topics/forms/modelforms.txt
M tests/admin_validation/tests.py
M tests/bug639/models.py
M tests/foreign_object/tests.py
M tests/forms_tests/tests/test_regressions.py
M tests/forms_tests/tests/tests.py
M tests/generic_relations/tests.py
M tests/generic_views/test_edit.py
M tests/generic_views/test_forms.py
M tests/generic_views/views.py
M tests/i18n/forms.py
M tests/inline_formsets/tests.py
M tests/model_forms/tests.py
M tests/model_forms_regress/tests.py
M tests/model_formsets/tests.py
M tests/model_formsets_regress/tests.py
M tests/model_inheritance_regress/tests.py
M tests/modeladmin/tests.py
M tests/timezones/forms.py

  Log Message:
  ---
  Fixed #19733 - deprecated ModelForms without 'fields' or 'exclude', and added 
'__all__' shortcut

This also updates all dependent functionality, including modelform_factory
 and modelformset_factory, and the generic views `ModelFormMixin`,
 `CreateView` and `UpdateView` which gain a new `fields` attribute.


Compare: https://github.com/django/django/compare/1906cb93609c...f026a519aea8

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 1906cb: Fixed conditional skipping of test for left/right ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1906cb93609ce6042f97939a04067a122f5719a6
  
https://github.com/django/django/commit/1906cb93609ce6042f97939a04067a122f5719a6
  Author: Aymeric Augustin 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M django/contrib/gis/tests/geoapp/tests.py

  Log Message:
  ---
  Fixed conditional skipping of test for left/right lookup types.

connection.ops.spatial_version is None for some backends (eg. MySQL) and
the comparison fails on Python 3 with TypeError.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11240: Compilemessages fails if a % character is at certain places in the .po file

[Django]

#11240: Compilemessages fails if a % character is at certain places in the .po 
file
-+-
 Reporter:  tback|Owner:
 Type:  Bug  |  garcia_marc
Component:   |   Status:  new
  Internationalization   |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by skyjur):

 Another workaround is to use alternative syntax for translation:

 {{{
 {{ _('Percent sign here % is not escaped.') }}
 }}}

 I guess that gettext might be looking for python syntaxed string-
 formatting in template files and is mislead because text string is
 followed directly by percent sign '''%}'''.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] a53d7a: Made gis_terms be a set, rather than a dict with N...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a53d7a0a50f12a1a731b81e646b55872717093bb
  
https://github.com/django/django/commit/a53d7a0a50f12a1a731b81e646b55872717093bb
  Author: Alex Gaynor 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M django/contrib/gis/db/backends/base.py
M django/contrib/gis/db/backends/mysql/operations.py
M django/contrib/gis/db/backends/oracle/operations.py
M django/contrib/gis/db/backends/postgis/operations.py
M django/contrib/gis/db/backends/spatialite/operations.py

  Log Message:
  ---
  Made gis_terms be a set, rather than a dict with None for all keys.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19934: Switch to a Python 3-compatible imaging library

[Django]

#19934: Switch to a Python 3-compatible imaging library
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  daniellindsley
  Cleanup/optimization   |   Status:  assigned
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 That works for me, I'm happy to review a patch along these lines.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19934: Switch to a Python 3-compatible imaging library

[Django]

#19934: Switch to a Python 3-compatible imaging library
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  daniellindsley
  Cleanup/optimization   |   Status:  assigned
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by daniellindsley):

 My vote is +0 for deprecating the PIL (in that Pillow becomes the
 "blessed" version), but I think detecting which is installed & using shims
 to gloss what little Django uses of either is a very doable task. By my
 count, the PIL/_imaging is only used in 4 files in Django (plus lots of
 test files) & none of the usages are particularly advanced.

 I'm also +0 on the error reporting shim, in that I think we need to be
 able to inform the user that their install may be mis-configured. The
 existing comment (& the detection going on) will have to change. Again,
 I'm of the belief we can shim over that & have some ideas on detection.

 The only thing I'd add to the plan you've laid out is """2.a.1) Create any
 necessary shims to aid Django in detecting which, if any, are installed &
 to aid in providing useful error messages about the installation."""

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 6634cb: Removed a test that didn't make sense; code could ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6634cb7b53bc35241e070f1896ff2fc439c19d0f
  
https://github.com/django/django/commit/6634cb7b53bc35241e070f1896ff2fc439c19d0f
  Author: Alex Gaynor 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M tests/many_to_one_regress/tests.py

  Log Message:
  ---
  Removed a test that didn't make sense; code could never be called the way the 
test was written.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20215: Consider disabling persisent connections by default

[Django]

#20215: Consider disabling persisent connections by default
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"3d595c3bc38cf939503b69ce7a2802d5663f85b9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d595c3bc38cf939503b69ce7a2802d5663f85b9"
 Fixed #20215 -- Disabled persistent connections by default.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3d595c: Fixed #20215 -- Disabled persistent connections by...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3d595c3bc38cf939503b69ce7a2802d5663f85b9
  
https://github.com/django/django/commit/3d595c3bc38cf939503b69ce7a2802d5663f85b9
  Author: Aymeric Augustin 
  Date:   2013-05-09 (Thu, 09 May 2013)

  Changed paths:
M django/db/utils.py
M docs/howto/deployment/checklist.txt
M docs/ref/databases.txt
M docs/ref/settings.txt
M docs/releases/1.6.txt

  Log Message:
  ---
  Fixed #20215 -- Disabled persistent connections by default.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20382: random TransactionManagementError during tests in _fixture_setup

[Django]

#20382: random TransactionManagementError during tests in _fixture_setup
-+-
 Reporter:  joao@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  TransactionManagementError |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 It is very likely that you have a test running two code paths
 concurrently:
   1. The test server is generating a response for a request generated by
 selenium
   2. The tests do not wait for that response to be generated, instead the
 tests continue parallel to the request

 When using in-memory SQLite3 the connection is shared between the test
 server and the test itself. As a result weird concurrency errors are
 possible. Most likely a test just before the failing one has an ongoing
 request, so that the next test's fixture loading happens concurrently to
 the request processing.

 A cause for this could be pretty much anything done via selenium scripting
 (for example click) but not waiting for the results of that action to be
 generated. See 50677b29af39ca670274fb45087415c883c78b04 and #19856 for a
 similar issue in Django's test suite.

 I will mark this as invalid as this is most likely not an issue in Django
 itself.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20382: random TransactionManagementError during tests in _fixture_setup

[Django]

#20382: random TransactionManagementError during tests in _fixture_setup
-+-
 Reporter:  joao@…   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.5
  (models, ORM)  |   Keywords:
 Severity:  Normal   |  TransactionManagementError
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Automated Django 1.5.1 tests randomly fail with
 **TransactionManagementError**. It is hard to track down because a failed
 test can run again, without any changes, and pass.

 I am NOT using the **@transaction.commit_manually** decorator and am aware
 of the need for manual commit/rollback when it is used.

 One view does have the **@transaction.commit_on_success** decorator. It
 does NOT have any commands for manual commit/rollback and from the docs I
 believe this is correct. But this might be irrelevant:
 1. the view is not called in every fail case
 1. error raised during fixture setup

 Test database is set to django.db.backends.sqlite3

 {{{
 Traceback (most recent call last):
   File "/usr/lib64/python2.7/site-packages/django/test/testcases.py", line
 259, in __call__
 self._pre_setup()
   File "/usr/lib64/python2.7/site-packages/django/test/testcases.py", line
 479, in _pre_setup
 self._fixture_setup()
   File "/usr/lib64/python2.7/site-packages/django/test/testcases.py", line
 518, in _fixture_setup
 **{'verbosity': 0, 'database': db_name, 'skip_validation': True})
   File "/usr/lib64/python2.7/site-
 packages/django/core/management/__init__.py", line 161, in call_command
 return klass.execute(*args, **defaults)
   File "/usr/lib64/python2.7/site-
 packages/django/core/management/base.py", line 255, in execute
 output = self.handle(*args, **options)
   File "/usr/lib64/python2.7/site-
 packages/django/core/management/commands/loaddata.py", line 234, in handle
 transaction.leave_transaction_management(using=using)
   File "/usr/lib64/python2.7/site-packages/django/db/transaction.py", line
 66, in leave_transaction_management
 connection.leave_transaction_management()
   File "/usr/lib64/python2.7/site-
 packages/django/db/backends/__init__.py", line 131, in
 leave_transaction_management
 "This code isn't under transaction management")
 TransactionManagementError: This code isn't under transaction management
 }}}

 == Selenium Tests ==
 * Using Selenium webdriver 2.32.0 (latest)
 * BrowserTestCase extends django.test.LiveServerTestCase
 * Test classes extend BrowserTestCase and inherit the same fixtures

 == Unit Tests ==
 * Error does NOT occur for tests extending django.test.TestCase or
 django.utils.unittest
 * Use the same fixtures as above

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches

[Django]

#19670: CachedFilesMixin Doesn't Limit Substitutions to Extension Matches
-+
 Reporter:  matthewwithanm   |Owner:  DrMeers
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.4
 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 DrMeers):

 * status:  new => assigned
 * owner:  nobody => DrMeers


Comment:

 I have a patch for this, just need to put the tests together.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20380: MySQL doesn't support dates below 1000 on Python 3.2

[Django]

#20380: MySQL doesn't support dates below 1000 on Python 3.2
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 I haven't reported this bug upstream, because I don't even where to report
 it, given the current fragmentation.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20377: BinaryField doesn't work on MySQL and Python 3

[Django]

#20377: BinaryField doesn't work on MySQL and Python 3
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Regarding MySQLdb, I haven't reported this bug upstream, because I don't
 even where to report it, given the current fragmentation.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20381: truncatechars template tag docs does not have Django version 1.4

[Django]

#20381: truncatechars template tag docs does not have Django version 1.4
-+-
 Reporter:  Simeon   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 We keep versionadded / changed directives for at most two versions. The
 next version (1.6) doesn't have annotations for things added / changed in
 1.4.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20379: request.POST.getlist fails when submitting a JS array of JS objects

[Django]

#20379: request.POST.getlist fails when submitting a JS array of JS objects
-+-
 Reporter:  Alex Krupp   |Owner:  nobody
   |   Status:  closed
 Type:  Uncategorized|  Version:  1.5
Component:  Uncategorized|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 I don't think your frontend code is valid. You should either properly
 serialize your objects client-side, or use a JSON structure, depending on
 the complexity of your objects.

 If you still think that Django is at fault, please provide the detailed
 POST structure of the HTTP request.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9256: Let the template parser remember it's root nodelist

[Django]

#9256: Let the template parser remember it's root nodelist
-+-
 Reporter:  SmileyChris  |Owner:
 Type:   |  SmileyChris
  Cleanup/optimization   |   Status:  closed
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:  wontfix
 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 SmileyChris):

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


Comment:

 It's not the reason, that was just an example of the usefulness of such a
 pointer.

 But it's not something I've heard any requests for, and since I opened it,
 I'll close it.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20377: BinaryField doesn't work on MySQL and Python 3

[Django]

#20377: BinaryField doesn't work on MySQL and Python 3
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 FWIW, I also tested this with PyMySQL (branch here:
 https://github.com/claudep/django/tree/pymysql) and it suffers from the
 exact same issue.
 See also https://github.com/petehunt/PyMySQL/issues/142

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19934: Switch to a Python 3-compatible imaging library

[Django]

#19934: Switch to a Python 3-compatible imaging library
-+-
 Reporter:  aaugustin|Owner:
 Type:   |  daniellindsley
  Cleanup/optimization   |   Status:  assigned
Component:  Python 3 |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by daniellindsley):

 * owner:  nobody => daniellindsley
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.