Re: [Django] #16334: cache_page decorator does not accept "cache" keyword argument

[Django]

#16334: cache_page decorator does not accept "cache" keyword argument
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ubernostrum):

 In [16816]:
 {{{
 #!CommitTicketReference repository="" revision="16816"
 [1.3.X] Fixed #16334: Make it quite clear that cache_page's 'cache'
 argument refers to the name of a cache in the CACHES setting. Backport of
 [16815] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16816 - django/branches/releases/1.3.X/docs/topics

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:58:34 -0700 (Sat, 10 Sep 2011)
New Revision: 16816

Modified:
   django/branches/releases/1.3.X/docs/topics/cache.txt
Log:
[1.3.X] Fixed #16334: Make it quite clear that cache_page's 'cache' argument 
refers to the name of a cache in the CACHES setting. Backport of [16815] from 
trunk.

Modified: django/branches/releases/1.3.X/docs/topics/cache.txt
===
--- django/branches/releases/1.3.X/docs/topics/cache.txt2011-09-11 
05:57:38 UTC (rev 16815)
+++ django/branches/releases/1.3.X/docs/topics/cache.txt2011-09-11 
05:58:34 UTC (rev 16816)
@@ -526,9 +526,10 @@
 requested, subsequent requests to that URL will use the cache.
 
 ``cache_page`` can also take an optional keyword argument, ``cache``,
-which directs the decorator to use a specific cache alias when caching view
-results. By default, the ``default`` alias will be used, but you can specify
-any cache alias you want::
+which directs the decorator to use a specific cache (from your
+:setting:`CACHES` setting) when caching view results. By default, the
+``default`` cache will be used, but you can specify any cache you
+want::
 
 @cache_page(60 * 15, cache="special_cache")
 def my_view(request):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16334: cache_page decorator does not accept "cache" keyword argument

[Django]

#16334: cache_page decorator does not accept "cache" keyword argument
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ubernostrum):

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


Comment:

 In [16815]:
 {{{
 #!CommitTicketReference repository="" revision="16815"
 Fixed #16334: Make it quite clear that cache_page's 'cache' argument
 refers to the name of a cache in the CACHES setting.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16815 - django/trunk/docs/topics

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:57:38 -0700 (Sat, 10 Sep 2011)
New Revision: 16815

Modified:
   django/trunk/docs/topics/cache.txt
Log:
Fixed #16334: Make it quite clear that cache_page's 'cache' argument refers to 
the name of a cache in the CACHES setting.

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2011-09-11 05:48:39 UTC (rev 16814)
+++ django/trunk/docs/topics/cache.txt  2011-09-11 05:57:38 UTC (rev 16815)
@@ -527,9 +527,10 @@
 requested, subsequent requests to that URL will use the cache.
 
 ``cache_page`` can also take an optional keyword argument, ``cache``,
-which directs the decorator to use a specific cache alias when caching view
-results. By default, the ``default`` alias will be used, but you can specify
-any cache alias you want::
+which directs the decorator to use a specific cache (from your
+:setting:`CACHES` setting) when caching view results. By default, the
+``default`` cache will be used, but you can specify any cache you
+want::
 
 @cache_page(60 * 15, cache="special_cache")
 def my_view(request):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16814 - django/branches/releases/1.3.X/docs/topics

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:48:39 -0700 (Sat, 10 Sep 2011)
New Revision: 16814

Modified:
   django/branches/releases/1.3.X/docs/topics/auth.txt
Log:
[1.3.X] Fixed #16094: Added clear example of how to refer to custom 
permissions. Backport of [16813] from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/auth.txt
===
--- django/branches/releases/1.3.X/docs/topics/auth.txt 2011-09-11 05:47:48 UTC 
(rev 16813)
+++ django/branches/releases/1.3.X/docs/topics/auth.txt 2011-09-11 05:48:39 UTC 
(rev 16814)
@@ -1251,17 +1251,20 @@
 ...
 class Meta:
 permissions = (
-("can_view", "Can see available tasks"),
-("can_change_status", "Can change the status of tasks"),
-("can_close", "Can remove a task by setting its status as 
closed"),
+("view_task", "Can see available tasks"),
+("change_task_status", "Can change the status of tasks"),
+("close_task", "Can remove a task by setting its status as 
closed"),
 )
 
 The only thing this does is create those extra permissions when you run
 :djadmin:`manage.py syncdb `. Your code is in charge of checking the
 value of these permissions when an user is trying to access the functionality
 provided by the application (viewing tasks, changing the status of tasks,
-closing tasks.)
+closing tasks.) Continuing the above example, the following checks if a user 
may
+view tasks:
 
+user.has_perm('app.view_task')
+
 API reference
 -
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16094: Documentation for Custom permissions is ambiguous.

[Django]

#16094: Documentation for Custom permissions is ambiguous.
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ubernostrum):

 In [16814]:
 {{{
 #!CommitTicketReference repository="" revision="16814"
 [1.3.X] Fixed #16094: Added clear example of how to refer to custom
 permissions. Backport of [16813] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16813 - django/trunk/docs/topics

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:47:48 -0700 (Sat, 10 Sep 2011)
New Revision: 16813

Modified:
   django/trunk/docs/topics/auth.txt
Log:
Fixed #16094: Added clear example of how to refer to custom permissions.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2011-09-11 05:45:26 UTC (rev 16812)
+++ django/trunk/docs/topics/auth.txt   2011-09-11 05:47:48 UTC (rev 16813)
@@ -1384,17 +1384,20 @@
 ...
 class Meta:
 permissions = (
-("can_view", "Can see available tasks"),
-("can_change_status", "Can change the status of tasks"),
-("can_close", "Can remove a task by setting its status as 
closed"),
+("view_task", "Can see available tasks"),
+("change_task_status", "Can change the status of tasks"),
+("close_task", "Can remove a task by setting its status as 
closed"),
 )
 
 The only thing this does is create those extra permissions when you run
 :djadmin:`manage.py syncdb `. Your code is in charge of checking the
 value of these permissions when an user is trying to access the functionality
 provided by the application (viewing tasks, changing the status of tasks,
-closing tasks.)
+closing tasks.) Continuing the above example, the following checks if a user 
may
+view tasks:
 
+user.has_perm('app.view_task')
+
 API reference
 -
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16094: Documentation for Custom permissions is ambiguous.

[Django]

#16094: Documentation for Custom permissions is ambiguous.
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ubernostrum):

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


Comment:

 In [16813]:
 {{{
 #!CommitTicketReference repository="" revision="16813"
 Fixed #16094: Added clear example of how to refer to custom permissions.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16812 - in django/branches/releases/1.3.X/docs: ref/models topics/http

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:45:26 -0700 (Sat, 10 Sep 2011)
New Revision: 16812

Modified:
   django/branches/releases/1.3.X/docs/ref/models/instances.txt
   django/branches/releases/1.3.X/docs/topics/http/urls.txt
Log:
[1.3.X] Fixed #16109: Corrected an inconsistency in URLconf examples for 
matching a numeric month. Backport of [16811] from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/models/instances.txt
===
--- django/branches/releases/1.3.X/docs/ref/models/instances.txt
2011-09-11 05:44:21 UTC (rev 16811)
+++ django/branches/releases/1.3.X/docs/ref/models/instances.txt
2011-09-11 05:45:26 UTC (rev 16812)
@@ -470,7 +470,7 @@
 
 Similarly, if you had a URLconf entry that looked like::
 
-(r'/archive/(?P\d{4})/(?P\d{1,2})/(?P\d{1,2})/$', 
archive_view)
+(r'/archive/(?P\d{4})/(?P\d{2})/(?P\d{2})/$', 
archive_view)
 
 ...you could reference this using ``permalink()`` as follows::
 
@@ -478,8 +478,8 @@
 def get_absolute_url(self):
 return ('archive_view', (), {
 'year': self.created.year,
-'month': self.created.month,
-'day': self.created.day})
+'month': self.created.strftime('%m'),
+'day': self.created.strftime('%d')})
 
 Notice that we specify an empty sequence for the second parameter in this case,
 because we only want to pass keyword parameters, not positional ones.

Modified: django/branches/releases/1.3.X/docs/topics/http/urls.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-09-11 
05:44:21 UTC (rev 16811)
+++ django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-09-11 
05:45:26 UTC (rev 16812)
@@ -103,8 +103,8 @@
 * ``/articles/2003`` would not match any of these patterns, because each
   pattern requires that the URL end with a slash.
 
-* ``/articles/2003/03/3/`` would match the final pattern. Django would call
-  the function ``news.views.article_detail(request, '2003', '03', '3')``.
+* ``/articles/2003/03/03/`` would match the final pattern. Django would 
call
+  the function ``news.views.article_detail(request, '2003', '03', '03')``.
 
 .. _Dive Into Python's explanation: 
http://diveintopython.org/regular_expressions/street_addresses.html#re.matching.2.3
 
@@ -127,7 +127,7 @@
 (r'^articles/2003/$', 'news.views.special_case_2003'),
 (r'^articles/(?P\d{4})/$', 'news.views.year_archive'),
 (r'^articles/(?P\d{4})/(?P\d{2})/$', 
'news.views.month_archive'),
-(r'^articles/(?P\d{4})/(?P\d{2})/(?P\d+)/$', 
'news.views.article_detail'),
+(r'^articles/(?P\d{4})/(?P\d{2})/(?P\d{2})/$', 
'news.views.article_detail'),
 )
 
 This accomplishes exactly the same thing as the previous example, with one
@@ -138,8 +138,8 @@
   ``news.views.month_archive(request, year='2005', month='03')``, instead
   of ``news.views.month_archive(request, '2005', '03')``.
 
-* A request to ``/articles/2003/03/3/`` would call the function
-  ``news.views.article_detail(request, year='2003', month='03', day='3')``.
+* A request to ``/articles/2003/03/03/`` would call the function
+  ``news.views.article_detail(request, year='2003', month='03', 
day='03')``.
 
 In practice, this means your URLconfs are slightly more explicit and less prone
 to argument-order bugs -- and you can reorder the arguments in your views'

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16109: Inconsistency in docs: Leading zero of numbers in URLconf

[Django]

#16109: Inconsistency in docs: Leading zero of numbers in URLconf
-+-
   Reporter: |  Owner:  nobody
  wegener92@…| Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ubernostrum):

 In [16812]:
 {{{
 #!CommitTicketReference repository="" revision="16812"
 [1.3.X] Fixed #16109: Corrected an inconsistency in URLconf examples for
 matching a numeric month. Backport of [16811] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16811 - in django/trunk/docs: ref/models topics/http

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:44:21 -0700 (Sat, 10 Sep 2011)
New Revision: 16811

Modified:
   django/trunk/docs/ref/models/instances.txt
   django/trunk/docs/topics/http/urls.txt
Log:
Fixed #16109: Corrected an inconsistency in URLconf examples for matching a 
numeric month.

Modified: django/trunk/docs/ref/models/instances.txt
===
--- django/trunk/docs/ref/models/instances.txt  2011-09-11 05:40:10 UTC (rev 
16810)
+++ django/trunk/docs/ref/models/instances.txt  2011-09-11 05:44:21 UTC (rev 
16811)
@@ -497,7 +497,7 @@
 
 Similarly, if you had a URLconf entry that looked like::
 
-(r'/archive/(?P\d{4})/(?P\d{1,2})/(?P\d{1,2})/$', 
archive_view)
+(r'/archive/(?P\d{4})/(?P\d{2})/(?P\d{2})/$', 
archive_view)
 
 ...you could reference this using ``permalink()`` as follows::
 
@@ -505,8 +505,8 @@
 def get_absolute_url(self):
 return ('archive_view', (), {
 'year': self.created.year,
-'month': self.created.month,
-'day': self.created.day})
+'month': self.created.strftime('%m'),
+'day': self.created.strftime('%d')})
 
 Notice that we specify an empty sequence for the second parameter in this case,
 because we only want to pass keyword parameters, not positional ones.

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2011-09-11 05:40:10 UTC (rev 
16810)
+++ django/trunk/docs/topics/http/urls.txt  2011-09-11 05:44:21 UTC (rev 
16811)
@@ -109,8 +109,8 @@
 * ``/articles/2003`` would not match any of these patterns, because each
   pattern requires that the URL end with a slash.
 
-* ``/articles/2003/03/3/`` would match the final pattern. Django would call
-  the function ``news.views.article_detail(request, '2003', '03', '3')``.
+* ``/articles/2003/03/03/`` would match the final pattern. Django would 
call
+  the function ``news.views.article_detail(request, '2003', '03', '03')``.
 
 .. _Dive Into Python's explanation: 
http://diveintopython.org/regular_expressions/street_addresses.html#re.matching.2.3
 
@@ -133,7 +133,7 @@
 (r'^articles/2003/$', 'news.views.special_case_2003'),
 (r'^articles/(?P\d{4})/$', 'news.views.year_archive'),
 (r'^articles/(?P\d{4})/(?P\d{2})/$', 
'news.views.month_archive'),
-(r'^articles/(?P\d{4})/(?P\d{2})/(?P\d+)/$', 
'news.views.article_detail'),
+(r'^articles/(?P\d{4})/(?P\d{2})/(?P\d{2})/$', 
'news.views.article_detail'),
 )
 
 This accomplishes exactly the same thing as the previous example, with one
@@ -144,8 +144,8 @@
   ``news.views.month_archive(request, year='2005', month='03')``, instead
   of ``news.views.month_archive(request, '2005', '03')``.
 
-* A request to ``/articles/2003/03/3/`` would call the function
-  ``news.views.article_detail(request, year='2003', month='03', day='3')``.
+* A request to ``/articles/2003/03/03/`` would call the function
+  ``news.views.article_detail(request, year='2003', month='03', 
day='03')``.
 
 In practice, this means your URLconfs are slightly more explicit and less prone
 to argument-order bugs -- and you can reorder the arguments in your views'

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16109: Inconsistency in docs: Leading zero of numbers in URLconf

[Django]

#16109: Inconsistency in docs: Leading zero of numbers in URLconf
-+-
   Reporter: |  Owner:  nobody
  wegener92@…| Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ubernostrum):

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


Comment:

 In [16811]:
 {{{
 #!CommitTicketReference repository="" revision="16811"
 Fixed #16109: Corrected an inconsistency in URLconf examples for matching
 a numeric month.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16810 - in django/tags/releases: . 1.2.7

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:40:10 -0700 (Sat, 10 Sep 2011)
New Revision: 16810

Added:
   django/tags/releases/1.2.7/
Log:
Tag 1.2.7.


Property changes on: django/tags/releases/1.2.7
___
Added: svn:ignore
   + build
dist
*.egg-info
MANIFEST
*.pyc

Added: svnmerge-integrated
   + 
/django/trunk:1-13360,13400,13434,13480,13574,13600,13638,13652,13664,13666,13668,13680,13683,13685,13687-13688,13690,13694,13696,13701-13702,13705,13709,13712,13715,13717,13732,13735,13859,14537,14545,14547,14630,14637,14762,14781,14783,14855,14928,15299,15602,15774,15777,15779,15783,15785,15787,15789,15883,15911
Added: svn:mergeinfo
   + /django/trunk:15602,15774,15777,15779,15783,15785,15787,15789,15883,15911
Added: svk:merge
   + bcc190cf-cafb-0310-a4f2-bffc1f526a37:/django/trunk:1054

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16293: Patch database documentation to explain how to return fetchall() as a dict rather than list.

[Django]

#16293: Patch database documentation to explain how to return fetchall() as a 
dict
rather than list.
---+---
   Reporter:  foxwhisper   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:  fixed|   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by ubernostrum):

 In [16809]:
 {{{
 #!CommitTicketReference repository="" revision="16809"
 [1.3.X] Fixed #16293: Document a way to return dicts with column names
 from a DB cursor. Backport of [16808] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16809 - django/branches/releases/1.3.X/docs/topics/db

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:38:50 -0700 (Sat, 10 Sep 2011)
New Revision: 16809

Modified:
   django/branches/releases/1.3.X/docs/topics/db/sql.txt
Log:
[1.3.X] Fixed #16293: Document a way to return dicts with column names from a 
DB cursor. Backport of [16808] from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/db/sql.txt
===
--- django/branches/releases/1.3.X/docs/topics/db/sql.txt   2011-09-11 
05:37:55 UTC (rev 16808)
+++ django/branches/releases/1.3.X/docs/topics/db/sql.txt   2011-09-11 
05:38:50 UTC (rev 16809)
@@ -236,6 +236,30 @@
 # Your code here...
 transaction.commit_unless_managed(using='my_db_alias')
 
+By default, the Python DB API will return results without their field
+names, which means you end up with a ``list`` of values, rather than a
+``dict``. At a small performance cost, you can return results as a
+``dict`` by using something like this::
+
+def dictfetchall(cursor):
+"Returns all rows from a cursor as a dict"
+desc = cursor.description
+return [
+dict(zip([col[0] for col in desc], row))
+for row in cursor.fetchall()
+]
+
+Here is an example of the difference between the two::
+
+>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
+>>> cursor.fetchall()
+((54360982L, None), (54360880L, None))
+
+>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
+>>> dictfetchall(cursor)
+[{'parent_id': None, 'id': 54360982L}, {'parent_id': None, 'id': 
54360880L}]
+
+
 .. _transactions-and-raw-sql:
 
 Transactions and raw SQL

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16808 - django/trunk/docs/topics/db

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:37:55 -0700 (Sat, 10 Sep 2011)
New Revision: 16808

Modified:
   django/trunk/docs/topics/db/sql.txt
Log:
Fixed #16293: Document a way to return dicts with column names from a DB cursor.

Modified: django/trunk/docs/topics/db/sql.txt
===
--- django/trunk/docs/topics/db/sql.txt 2011-09-11 05:32:14 UTC (rev 16807)
+++ django/trunk/docs/topics/db/sql.txt 2011-09-11 05:37:55 UTC (rev 16808)
@@ -240,6 +240,30 @@
 # Your code here...
 transaction.commit_unless_managed(using='my_db_alias')
 
+By default, the Python DB API will return results without their field
+names, which means you end up with a ``list`` of values, rather than a
+``dict``. At a small performance cost, you can return results as a
+``dict`` by using something like this::
+
+def dictfetchall(cursor):
+"Returns all rows from a cursor as a dict"
+desc = cursor.description
+return [
+dict(zip([col[0] for col in desc], row))
+for row in cursor.fetchall()
+]
+
+Here is an example of the difference between the two::
+
+>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
+>>> cursor.fetchall()
+((54360982L, None), (54360880L, None))
+
+>>> cursor.execute("SELECT id, parent_id from test LIMIT 2");
+>>> dictfetchall(cursor)
+[{'parent_id': None, 'id': 54360982L}, {'parent_id': None, 'id': 
54360880L}]
+
+
 .. _transactions-and-raw-sql:
 
 Transactions and raw SQL

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16293: Patch database documentation to explain how to return fetchall() as a dict rather than list.

[Django]

#16293: Patch database documentation to explain how to return fetchall() as a 
dict
rather than list.
---+---
   Reporter:  foxwhisper   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:  fixed|   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by ubernostrum):

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


Comment:

 In [16808]:
 {{{
 #!CommitTicketReference repository="" revision="16808"
 Fixed #16293: Document a way to return dicts with column names from a DB
 cursor.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16807 - django/branches/releases/1.3.X/docs/ref/contrib/admin

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:32:14 -0700 (Sat, 10 Sep 2011)
New Revision: 16807

Modified:
   django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt
Log:
[1.3.X] Fixed #16552: Noted that contrib.sessions is a requirement for the 
admin. Backport of [16806] from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt 
2011-09-11 05:31:00 UTC (rev 16806)
+++ django/branches/releases/1.3.X/docs/ref/contrib/admin/index.txt 
2011-09-11 05:32:14 UTC (rev 16807)
@@ -19,8 +19,10 @@
 1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS`
setting.
 
-2. Admin has two dependencies - :mod:`django.contrib.auth` and
-   :mod:`django.contrib.contenttypes`. If these applications are not
+2. The admin has four dependencies - :mod:`django.contrib.auth`,
+   :mod:`django.contrib.contenttypes`,
+   :mod:`django.contrib.messages` and
+   :mod:`django.contrib.sessions`.  If these applications are not
in your :setting:`INSTALLED_APPS` list, add them.
 
 3. Determine which of your application's models should be editable in the

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16552: Missing app in Django admin dependency list.

[Django]

#16552: Missing app in Django admin dependency list.
+---
   Reporter:  zelo  |  Owner:  teraom
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Documentation
Version:  1.3   |   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 |
+---

Comment (by ubernostrum):

 In [16807]:
 {{{
 #!CommitTicketReference repository="" revision="16807"
 [1.3.X] Fixed #16552: Noted that contrib.sessions is a requirement for the
 admin. Backport of [16806] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16552: Missing app in Django admin dependency list.

[Django]

#16552: Missing app in Django admin dependency list.
+---
   Reporter:  zelo  |  Owner:  teraom
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Documentation
Version:  1.3   |   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 ubernostrum):

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


Comment:

 In [16806]:
 {{{
 #!CommitTicketReference repository="" revision="16806"
 Fixed #16552: Noted that contrib.sessions is a requirement for the admin.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16806 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: ubernostrum
Date: 2011-09-10 22:31:00 -0700 (Sat, 10 Sep 2011)
New Revision: 16806

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #16552: Noted that contrib.sessions is a requirement for the admin.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-09-11 04:06:29 UTC 
(rev 16805)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-09-11 05:31:00 UTC 
(rev 16806)
@@ -19,10 +19,11 @@
 1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS`
setting.
 
-2. Admin has three dependencies - :mod:`django.contrib.auth`,
-   :mod:`django.contrib.contenttypes` and :mod:`django.contrib.messages`.
-   If these applications are not in your :setting:`INSTALLED_APPS` list,
-   add them.
+2. The admin has four dependencies - :mod:`django.contrib.auth`,
+   :mod:`django.contrib.contenttypes`,
+   :mod:`django.contrib.messages` and
+   :mod:`django.contrib.sessions`.  If these applications are not
+   in your :setting:`INSTALLED_APPS` list, add them.
 
 3. Add ``django.contrib.messages.context_processors.messages`` to
:setting:`TEMPLATE_CONTEXT_PROCESSORS` and

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15945: Thread locals note

[Django]

#15945: Thread locals note
-+-
   Reporter:  sorl   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ubernostrum):

 * status:  reopened => closed
 * ui_ux:   => 0
 * resolution:   => fixed


Comment:

 Since Django has, for years, supported a much simpler way to accomplish
 the things people wanted that for, I've simply deleted the wiki page.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16079: Clarify that handler404 and handler500 only applies to project

[Django]

#16079: Clarify that handler404 and handler500 only applies to project
-+-
   Reporter:  Martin |  Owner:  nobody
  Vilcans  | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by ubernostrum):

 In [16805]:
 {{{
 #!CommitTicketReference repository="" revision="16805"
 [1.3.X] Fixed #16079: Clarified (for real this time) how handler404 and
 handler500 work, and that they only work in a root URLconf. Backport of
 [16804] from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16805 - in django/branches/releases/1.3.X/docs: intro topics/http

[noreply]

Author: ubernostrum
Date: 2011-09-10 21:06:29 -0700 (Sat, 10 Sep 2011)
New Revision: 16805

Modified:
   django/branches/releases/1.3.X/docs/intro/tutorial03.txt
   django/branches/releases/1.3.X/docs/topics/http/urls.txt
   django/branches/releases/1.3.X/docs/topics/http/views.txt
Log:
[1.3.X] Fixed #16079: Clarified (for real this time) how handler404 and 
handler500 work, and that they only work in a root URLconf. Backport of [16804] 
from trunk.

Modified: django/branches/releases/1.3.X/docs/intro/tutorial03.txt
===
--- django/branches/releases/1.3.X/docs/intro/tutorial03.txt2011-09-11 
04:01:41 UTC (rev 16804)
+++ django/branches/releases/1.3.X/docs/intro/tutorial03.txt2011-09-11 
04:06:29 UTC (rev 16805)
@@ -357,11 +357,13 @@
 Write a 404 (page not found) view
 =
 
-When you raise :exc:`~django.http.Http404` from within a view, Django will load
-a special view devoted to handling 404 errors. It finds it by looking for the
-variable ``handler404``, which is a string in Python dotted syntax -- the same
-format the normal URLconf callbacks use. A 404 view itself has nothing special:
-It's just a normal view.
+When you raise :exc:`~django.http.Http404` from within a view, Django
+will load a special view devoted to handling 404 errors. It finds it
+by looking for the variable ``handler404`` in your root URLconf (and
+only in your root URLconf; setting ``handler404`` anywhere else will
+have no effect), which is a string in Python dotted syntax -- the same
+format the normal URLconf callbacks use. A 404 view itself has nothing
+special: It's just a normal view.
 
 You normally won't have to bother with writing 404 views. By default, URLconfs
 have the following line up top::
@@ -393,9 +395,9 @@
 Write a 500 (server error) view
 ===
 
-Similarly, URLconfs may define a ``handler500``, which points to a view to call
-in case of server errors. Server errors happen when you have runtime errors in
-view code.
+Similarly, your root URLconf may define a ``handler500``, which points
+to a view to call in case of server errors. Server errors happen when
+you have runtime errors in view code.
 
 Use the template system
 ===

Modified: django/branches/releases/1.3.X/docs/topics/http/urls.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-09-11 
04:01:41 UTC (rev 16804)
+++ django/branches/releases/1.3.X/docs/topics/http/urls.txt2011-09-11 
04:06:29 UTC (rev 16805)
@@ -54,6 +54,10 @@
:class:`~django.http.HttpRequest` as its first argument and any values
captured in the regex as remaining arguments.
 
+5. If no regex matches, or if an exception is raised during any
+   point in this process, Django invokes an appropriate
+   error-handling view. See `Error handling`_ below.
+
 Example
 ===
 
@@ -246,6 +250,31 @@
 ``patterns()`` and is only relevant when you're passing a string as the
 ``view`` parameter.
 
+include
+---
+
+.. function:: include()
+
+A function that takes a full Python import path to another URLconf module that
+should be "included" in this place.
+
+:func:`include` also accepts as an argument an iterable that returns URL
+patterns.
+
+See `Including other URLconfs`_ below.
+
+Error handling
+==
+
+When Django can't find a regex matching the requested URL, or when an
+exception is raised, Django will invoke an error-handling view. The
+views to use for these cases are specified by two variables which can
+be set in your root URLconf. Setting these variables in any other
+URLconf will have no effect.
+
+See the documentation on :ref:`customizing error views
+` for more details.
+
 handler404
 --
 
@@ -275,19 +304,6 @@
 .. versionchanged:: 1.2
 Previous versions of Django only accepted strings representing import 
paths.
 
-include

-
-.. function:: include()
-
-A function that takes a full Python import path to another URLconf module that
-should be "included" in this place.
-
-:func:`include` also accepts as an argument an iterable that returns URL
-patterns.
-
-See `Including other URLconfs`_ below.
-
 Notes on capturing text in URLs
 ===
 

Modified: django/branches/releases/1.3.X/docs/topics/http/views.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/views.txt   2011-09-11 
04:01:41 UTC (rev 16804)
+++ django/branches/releases/1.3.X/docs/topics/http/views.txt   2011-09-11 
04:06:29 UTC (rev 16805)
@@ -122,6 +122,8 @@
 template that is displayed when a 404 error is raised. This template should be
 called ``404.html`` and located in the top level of your template tree.
 
+.. _customizing-error-views:
+
 Customizing error views
 ===
 

-- 
You received this message because y

Re: [Django] #16079: Clarify that handler404 and handler500 only applies to project

[Django]

#16079: Clarify that handler404 and handler500 only applies to project
-+-
   Reporter:  Martin |  Owner:  nobody
  Vilcans  | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ubernostrum):

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


Comment:

 In [16804]:
 {{{
 #!CommitTicketReference repository="" revision="16804"
 Fixed #16079: Clarified (for real this time) how handler404 and handler500
 work, and that they only work in a root URLconf.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16804 - in django/trunk/docs: intro topics/http

[noreply]

Author: ubernostrum
Date: 2011-09-10 21:01:41 -0700 (Sat, 10 Sep 2011)
New Revision: 16804

Modified:
   django/trunk/docs/intro/tutorial03.txt
   django/trunk/docs/topics/http/urls.txt
   django/trunk/docs/topics/http/views.txt
Log:
Fixed #16079: Clarified (for real this time) how handler404 and handler500 
work, and that they only work in a root URLconf.

Modified: django/trunk/docs/intro/tutorial03.txt
===
--- django/trunk/docs/intro/tutorial03.txt  2011-09-11 02:28:08 UTC (rev 
16803)
+++ django/trunk/docs/intro/tutorial03.txt  2011-09-11 04:01:41 UTC (rev 
16804)
@@ -356,11 +356,13 @@
 Write a 404 (page not found) view
 =
 
-When you raise :exc:`~django.http.Http404` from within a view, Django will load
-a special view devoted to handling 404 errors. It finds it by looking for the
-variable ``handler404``, which is a string in Python dotted syntax -- the same
-format the normal URLconf callbacks use. A 404 view itself has nothing special:
-It's just a normal view.
+When you raise :exc:`~django.http.Http404` from within a view, Django
+will load a special view devoted to handling 404 errors. It finds it
+by looking for the variable ``handler404`` in your root URLconf (and
+only in your root URLconf; setting ``handler404`` anywhere else will
+have no effect), which is a string in Python dotted syntax -- the same
+format the normal URLconf callbacks use. A 404 view itself has nothing
+special: It's just a normal view.
 
 You normally won't have to bother with writing 404 views. By default, URLconfs
 have the following line up top::
@@ -392,9 +394,9 @@
 Write a 500 (server error) view
 ===
 
-Similarly, URLconfs may define a ``handler500``, which points to a view to call
-in case of server errors. Server errors happen when you have runtime errors in
-view code.
+Similarly, your root URLconf may define a ``handler500``, which points
+to a view to call in case of server errors. Server errors happen when
+you have runtime errors in view code.
 
 Use the template system
 ===

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2011-09-11 02:28:08 UTC (rev 
16803)
+++ django/trunk/docs/topics/http/urls.txt  2011-09-11 04:01:41 UTC (rev 
16804)
@@ -60,6 +60,10 @@
:class:`~django.http.HttpRequest` as its first argument and any values
captured in the regex as remaining arguments.
 
+5. If no regex matches, or if an exception is raised during any
+   point in this process, Django invokes an appropriate
+   error-handling view. See `Error handling`_ below.
+
 Example
 ===
 
@@ -252,6 +256,31 @@
 ``patterns()`` and is only relevant when you're passing a string as the
 ``view`` parameter.
 
+include
+---
+
+.. function:: include()
+
+A function that takes a full Python import path to another URLconf module that
+should be "included" in this place.
+
+:func:`include` also accepts as an argument an iterable that returns URL
+patterns.
+
+See `Including other URLconfs`_ below.
+
+Error handling
+==
+
+When Django can't find a regex matching the requested URL, or when an
+exception is raised, Django will invoke an error-handling view. The
+views to use for these cases are specified by two variables which can
+be set in your root URLconf. Setting these variables in any other
+URLconf will have no effect.
+
+See the documentation on :ref:`customizing error views
+` for more details.
+
 handler404
 --
 
@@ -281,19 +310,6 @@
 .. versionchanged:: 1.2
 Previous versions of Django only accepted strings representing import 
paths.
 
-include

-
-.. function:: include()
-
-A function that takes a full Python import path to another URLconf module that
-should be "included" in this place.
-
-:func:`include` also accepts as an argument an iterable that returns URL
-patterns.
-
-See `Including other URLconfs`_ below.
-
 Notes on capturing text in URLs
 ===
 

Modified: django/trunk/docs/topics/http/views.txt
===
--- django/trunk/docs/topics/http/views.txt 2011-09-11 02:28:08 UTC (rev 
16803)
+++ django/trunk/docs/topics/http/views.txt 2011-09-11 04:01:41 UTC (rev 
16804)
@@ -122,6 +122,8 @@
 template that is displayed when a 404 error is raised. This template should be
 called ``404.html`` and located in the top level of your template tree.
 
+.. _customizing-error-views:
+
 Customizing error views
 ===
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, v

Re: [Django] #6642: Fixtures (dumpdata/loaddata) do not check for illegal date types

[Django]

#6642: Fixtures (dumpdata/loaddata) do not check for illegal date types
-+-
   Reporter:  trbs   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  fixtures, dumpdata,
   Triage Stage:  Accepted   |  loaddata
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by carljm):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Dates that are all 0s should not be dumped as null - that's the bug, and
 should be 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6632: FormSet, ModelFormSet, InlineFormSet and inlines for newforms in trunk

[Django]

#6632: FormSet, ModelFormSet, InlineFormSet and inlines for newforms in trunk
-+-
   Reporter:  Petr   |  Owner:  nobody
  Marhoun| Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  invalid|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  reopened => closed
 * ui_ux:   => 0
 * resolution:   => invalid
 * easy:   => 0


Comment:

 Some of this we have already (formsets) and the remainder need to be filed
 as separate, independent tickets. This is way too much to cram into one
 ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6631: Additional options for newforms

[Django]

#6631: Additional options for newforms
-+-
   Reporter:  Petr   |  Owner:  nobody
  Marhoun| Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  post10
Version:  SVN|  Has patch:  1
 Resolution:  invalid|Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => invalid
 * easy:   => 0


Comment:

 A few of these items have been fixed already, the remainder should be
 opened as individual tickets, since they aren't interdependent.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6630: Fieldsets for newforms

[Django]

#6630: Fieldsets for newforms
-+-
   Reporter:  Petr   |  Owner:  nobody
  Marhoun| Status:  new
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  feature
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  1  |
-+-
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 This feature is accepted, its never really been DDN (although there are
 certainly design decisions to be made in the implementation).

 This feature needs to remain pretty barebones and structural. Its useful
 to have information in Python code about the fieldsets structure of a
 form, so it can be used with generic reusable rendering templates. Any
 more in-depth presentation-related tweaking should be done in templates,
 though, not via a complicated Python data structure.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6586: extends tag should compile static parents

[Django]

#6586: extends tag should compile static parents
-+-
   Reporter:  fredd4@…   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  extends
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  reopened => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 This is already solved in the general case by the caching template loader
 - works for all template loading and compiling, not just as a special case
 for extends tag. So there's no need to complicate the code with a special
 case for extends.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6585: admin foreignkey dropdown does not adhere to model's admin ordering

[Django]

#6585: admin foreignkey dropdown does not adhere to model's admin ordering
--+---
   Reporter:  gwilson |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.admin
Version:  newforms-admin  |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  1   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by carljm):

 * keywords:  nfa-someday =>
 * stage:  Design decision needed => Accepted


Comment:

 The original report here is correct, the ModelAdmin ordering should take
 precedence if set, even for related-field dropdowns. We don't need to add
 additional complexity in the form of new options specifically for related
 fields; customization at that level is already possible by overriding
 methods on the ModelAdmin of the model with the FK.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6527: A bug in HttpResponse with iterators

[Django]

#6527: A bug in HttpResponse  with iterators
-+-
   Reporter:  daonb  |  Owner:  ccahoon
| Status:  new
   Type:  Bug|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  http iterators
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by carljm):

 Alex and I looked at this at the sprint and thought there had been
 extensive discussion of iterable responses and middleware during the
 TemplateResponse discussions, but weren't sure what the conclusions of
 that discussion were. It doesn't seem that the relevant HttpResponse code
 has changed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6490: Accept variable keyword args in authentication

[Django]

#6490: Accept variable keyword args in authentication
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  reopened
   Type:  New|  Component:  contrib.auth
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

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


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6490: Accept variable keyword args in authentication

[Django]

#6490: Accept variable keyword args in authentication
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  closed
   Type:  New|  Component:  contrib.auth
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  wontfix|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 This is already addressed. Auth backends' authenticate methods can accept
 any credentials. The main django.contrib.auth.authenticate() function
 accepts arbitrary keyword argument credentials and catches the TypeError
 if the credentials are wrong for a given 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6519: admin: "Can change user" permission allows to change all others even w/o "Can change permissions"

[Django]

#6519: admin: "Can change user" permission allows to change all others even w/o
"Can change permissions"
-+-
   Reporter: |  Owner:  thauber
  raik.gruenberg@…   | Status:  closed
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  permissions nfa-
Version:  newforms-  |  someday
  admin  |  Has patch:  0
 Resolution:  invalid|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  assigned => closed
 * ui_ux:   => 0
 * resolution:   => invalid
 * easy:   => 0


Comment:

 This ticket resulted from a confusion about the wording of permissions;
 not seeing a clear action proposal here.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6498: Add case insensitive model ordering

[Django]

#6498: Add case insensitive model ordering
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 The idea of case insensitive ordering is accepted, some more thought
 should be put into the API, * for case-sensitive isn't particularly
 intuitive.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6517: manage.py dbshell does not get charset from database_options

[Django]

#6517: manage.py dbshell does not get charset from database_options
-+-
   Reporter:  tvrg   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by carljm):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 We should look into whether this is needed on other backends as well, not
 just MySQL.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6490: Accept variable keyword args in authentication

[Django]

#6490: Accept variable keyword args in authentication
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  closed
   Type:  New|  Component:  contrib.auth
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

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


Comment:

 Sorry, wrong resolution, reclosing as 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6485: Split off file-serving capability

[Django]

#6485: Split off file-serving capability
-+-
   Reporter:  Bastian|  Owner:  nobody
  Kleineidam   | Status:  closed
   Type:  New|  Component:  Uncategorized
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  wontfix|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 The recommended way to do permission-protected static files is by sending
 an X-SendFile header to the front-end webserver, and there are good third-
 party tools available for doing that with Django. Django's file-serving
 code is not intended for production use.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6418: Databrowse not allowing download of FieldType: FileField

[Django]

#6418: Databrowse not allowing download of FieldType: FileField
-+-
   Reporter:  Manish |  Owner:  nobody
  Singh   | Status:  new
   Type:  New|  Component:  contrib.databrowse
  feature|   Severity:  Normal
  Milestone: |   Keywords:  databrowse
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage: |  Easy pickings:  0
  Someday/Maybe  |
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Someday/Maybe


Comment:

 Marking this as someday/maybe, databrowse does not currently have an
 owner, or any particular direction (much less active development).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16803 - django/trunk/docs/releases

[noreply]

Author: carljm
Date: 2011-09-10 19:28:08 -0700 (Sat, 10 Sep 2011)
New Revision: 16803

Added:
   django/trunk/docs/releases/1.2.7.txt
Modified:
   django/trunk/docs/releases/index.txt
Log:
Added basic release notes for 1.2.7.

Added: django/trunk/docs/releases/1.2.7.txt
===
--- django/trunk/docs/releases/1.2.7.txt(rev 0)
+++ django/trunk/docs/releases/1.2.7.txt2011-09-11 02:28:08 UTC (rev 
16803)
@@ -0,0 +1,16 @@
+==
+Django 1.2.7 release notes
+==
+
+*September 10, 2011*
+
+Welcome to Django 1.2.7!
+
+This is the seventh bugfix/security release in the Django 1.2 series. It
+replaces Django 1.2.6 due to problems with the 1.2.6 release tarball. 
+Django 1.2.7 is a recommended upgrade for all users of any Django release in
+the 1.2.X series.
+
+For more information, see the `release advisory`_.
+
+.. _release advisory: https://www.djangoproject.com/weblog/2011/sep/10/127/

Modified: django/trunk/docs/releases/index.txt
===
--- django/trunk/docs/releases/index.txt2011-09-11 01:12:11 UTC (rev 
16802)
+++ django/trunk/docs/releases/index.txt2011-09-11 02:28:08 UTC (rev 
16803)
@@ -35,6 +35,7 @@
 .. toctree::
:maxdepth: 1
 
+   1.2.7
1.2.6
1.2.5
1.2.4

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6417: Small change in generic realtions

[Django]

#6417: Small change in generic realtions
-+-
   Reporter:  Adrian |  Owner:  nobody
   | Status:  closed
   Type:  New|  Component:
  feature|  contrib.contenttypes
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => duplicate
 * easy:   => 0


Comment:

 Closing as a dupe of #16027 because Julien accepted that one, and it has a
 more recent patch/discussion.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
---+--
   Reporter:  mbeachy@…|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Core (Other)
Version:  SVN  |   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 carljm):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 This seems like a useful feature that can be added in just a few lines of
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14039: FileField special-casing breaks MultiValueField including a FileField

[Django]

#14039: FileField special-casing breaks MultiValueField including a FileField
+---
   Reporter:  carljm|  Owner:  carljm
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:  sprintSep2010
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by carljm):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 #6405 closed as duplicate of this.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6405: ComboField/MultiValueField with FileField and passing initial data trough

[Django]

#6405: ComboField/MultiValueField with FileField and passing initial data trough
-+-
   Reporter:  Øyvind |  Owner:  nobody
  Saltvik  | Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  pass initial trough
Version:  SVN|  newforms multivaluefield
 Resolution:  duplicate  |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => duplicate
 * easy:   => 0


Comment:

 Closing as duplicate of #14039, which has a fuller description of the
 problem and a more up to date 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6396: [newforms-admin] Customization-unfriendly admin template tags should die

[Django]

#6396: [newforms-admin] Customization-unfriendly admin template tags should die
-+-
   Reporter:  korpios|  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  nfa-someday
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 I think the situation has improved recently, much code has been split off
 into utility functions, as a meta-point cleaning up code like this is
 always of value.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6388: as_p produce invalid HTML for RadioSelect

[Django]

#6388: as_p produce invalid HTML for RadioSelect
--+
   Reporter:  batiste |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Forms
Version:  SVN |   Severity:  Normal
 Resolution:  wontfix |   Keywords:
   Triage Stage:  Design decision needed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  1
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 This is a minor bug and there's no reasonable backwards-compatible way
 around it. As_p is going to continue to render with paragraph tags, and UL
 is the logical default markup for a radio select. The fix is to not use
 as_p if you have a radio select field, or to customize your radio field
 renderer as documented above (and hopefully soon we'll have an even better
 way with #15667). Methods like as_p are just for quick prototyping - if
 you care about your markup, render your form in your own templates.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6378: Capture arbitrary output as a template variable

[Django]

#6378: Capture arbitrary output as a template variable
-+-
   Reporter:  kcarnold   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 This needs a stronger use-case justification. Many of the use-cases for
 this are indications that the template should be re-structured, or an {%
 include %} could be used instead. Capturing output like this is yet
 another entirely different mental model for organizing and reusing
 template code, and we already have at least two of those - we need strong
 justification to add another to core (especially since it can work just
 fine as an external snippet/library).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6343: % symbols not escaped in db_column column names when preparing queries

[Django]

#6343: % symbols not escaped in db_column column names when preparing queries
-+-
   Reporter:  Daniel |  Owner:  nobody
  Pope| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carljm):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 This either needs to be fixed, or if that's not technically feasible in a
 sane way, documented.

 #11391 closed as duplicate of this, also raises the issue that this can
 happen with field names, not just table names. That should also be
 addressed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11391: Legacy Database "%" escaping not documented

[Django]

#11391: Legacy Database "%" escaping not documented
-+-
   Reporter:  Greg   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  1.0|  commands)
 Resolution:  duplicate  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  legacy, models.py
Needs documentation:  0  |  inspectdb
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by Alex):

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


Comment:

 Marking as a duplicate of #6343.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6272: django.utils.translation.ugettext_lazy needs __add__ support

[Django]

#6272: django.utils.translation.ugettext_lazy needs __add__ support
-+-
   Reporter:  Tai Lee|  Owner:  nobody
   | Status:  closed
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:  ugettext_lazy
Version:  SVN|  unicode concatenate
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Many magic methods aren't supported by lazy proxies - the solution is if
 you have something that might be a lazy proxy, coerce it to what you need
 so you know what you're dealing with. `"Blah" + unicode(foo)` is not
 significantly more onerous than `"Blah" + foo`.

 (Also, it appears that `foo + "blah"`, where `foo` is a lazy proxy, works
 fine. It's the other direction that doesn't seem to work, so it's really
 `__radd__` that would be needed.)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6439: support for filter methods on date field attributes

[Django]

#6439: support for filter methods on date field attributes
-+-
   Reporter:  omat@… |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  datefield, database
   Triage Stage:  Accepted   |  api, filter methods
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Accepted, though I think it's a dude of another ticket.  Really this is
 representative of a large issue about fields defining their own lookups,
 and chaining those.  But I don't know the dupe's #, so I'll let this be
 open.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6251: Allow rename of project directory

[Django]

#6251: Allow rename of project directory
-+-
   Reporter:  Noam   |  Owner:  nobody
  Raphael   | Status:  closed
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  duplicate  |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => duplicate
 * easy:   => 0


Comment:

 The root cause of this is #15372, manage.py adding the parent directory to
 sys.path. It shouldn't do that at all - adding a PROJECT_NAME setting is
 not a real solution. Marking duplicate.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15372: Django modifies the module name while importing it.

[Django]

#15372: Django modifies the module name while importing it.
-+-
   Reporter:  Jorge  |  Owner:  russellm
  Vargas | Status:  reopened
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  duplicate =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Bug


Comment:

 Reopening - this was closed as duplicate of #15064, but the fix for #15064
 didn't actually deal with the core problem, the sys.path mangling done by
 setup_environ. This ticket is the clearest explanation of that problem
 that I can find, and thus should remain open.

 To be clear, this ticket will be fixed when Django is no longer mucking
 with sys.path, not just if the mucking is done with an absolute path; thus
 the attached patch is not adequate.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15367: Improved Auth Password Hashing

[Django]

#15367: Improved Auth Password Hashing
-+-
   Reporter:  poswald|  Owner:  jart
   Type:  New| Status:  new
  feature|  Component:  contrib.auth
  Milestone:  1.4|   Severity:  Normal
Version:  1.2|   Keywords:  password, hash,
 Resolution: |  hashing, bcrypt, scrypt, pbkdf2,
   Triage Stage:  Accepted   |  sha2, sha1
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by jart):

 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6327: Add has_module_permission to ModelAdmin

[Django]

#6327: Add has_module_permission to ModelAdmin
---+---
   Reporter:  chrj |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by Alex):

 * keywords:  newforms-admin =>
 * ui_ux:   => 0
 * version:  newforms-admin => SVN
 * easy:   => 0
 * stage:  Design decision needed => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6056: another auth decorator permission_required_or_message propose

[Django]

#6056: another auth decorator permission_required_or_message propose
-+-
   Reporter:  yong27@…   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  auth decorator
 Resolution:  wontfix|  permission_required
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 After discussion with Carl: we're wontfixing this, because the desired
 behavior on a permission failure is project specific, and thus cannot live
 in Django, and this decorator can easily live outside of Django.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6055: GenericRelation and db_column lookups

[Django]

#6055: GenericRelation and db_column lookups
-+-
   Reporter:  dcramer|  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => needsinfo
 * easy:   => 0


Comment:

 Closing needsinfo, as the report doesn't clearly indicate what the bug is,
 how to reproduce it, or what's the desired alternative behavior.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6028: add compatibility with glibc2 MD5-based crypt passwords

[Django]

#6028: add compatibility with glibc2 MD5-based crypt passwords
-+-
   Reporter:  akaihola   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  auth password crypt
 Resolution:  wontfix|  mp5
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 While we don't have it yet, Paul McMillan and others are working on a more
 proper infrastructure for allowing different password hashing schemes.
 This will be able to live outside Django once it lands, and thus no action
 should be taken inside Django for this.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5992: even more granular error output

[Django]

#5992: even more granular error output
-+-
   Reporter:  Max|  Owner:  nobody
  Derkachev | Status:  closed
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  wontfix|Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Modifying error display via a custom ErrorList class is only necessary if
 you are rendering your form with e.g. {{ form.as_p }}. Those methods are
 only intended for quick prototyping - if you really need to control your
 display markup, you should render your form in templates. If you do that,
 and you're at the point where you're writing {{ form.field_name.errors }}
 in your template, you can instead write {% for error in
 form.field_name.errors %}...{% endfor %} and display the errors however
 you want, bypassing the built-in ErrorList rendering entirely. And that
 can be wrapped up into an {% include %} and made just as concise.

 Closing this wontfix, the preferred approach is to put as much markup as
 possible in templates rather than Python 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16455: Postgis 2.0 Compatibility

[Django]

#16455: Postgis 2.0 Compatibility
---+-
   Reporter:  ckarrie  |  Owner:  jbronn
   Type:  New feature  | Status:  assigned
  Milestone:  1.4  |  Component:  GIS
Version:  1.3-beta |   Severity:  Normal
 Resolution:   |   Keywords:  postgis 2.0
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+-
Changes (by jbronn):

 * owner:  nobody => jbronn
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15516: Update the ticket life cycle diagram

[Django]

#15516: Update the ticket life cycle diagram
-+-
   Reporter:  ramiro |  Owner:  tswicegood
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Looks pretty awesome! I just had a few remarks:

 * "Needs Info" is a resolution, which means that the ticket will get
 closed. The ticket may then be reopened if more information can be
 provided.
 * In principle, no ticket in the "Accepted" stage would directly be
 checked in. In general someone first needs to review the patch and then
 move it to "Ready for checkin" before a committer checks it in. A rare
 exception to this principle is a committer jumps this step if he/she
 approves the patch and is ready to commit it right away.
 * An free and open format would be preferable for the source file to make
 sure anyone can update it. Maybe SVG?

 Thanks for the great work!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16804: Problem with Django 1.2.6 - Patch isn't in online tar.gz

[Django]

#16804: Problem with Django 1.2.6 - Patch isn't in online tar.gz
+-
   Reporter:  Stephane  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Uncategorized
Version:  1.2   |   Severity:  Release blocker
 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 ubernostrum):

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


Comment:

 1.2.7 has been issued, and includes the full patch set.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16802 - django/trunk/docs/howto/deployment

[noreply]

Author: julien
Date: 2011-09-10 18:12:11 -0700 (Sat, 10 Sep 2011)
New Revision: 16802

Modified:
   django/trunk/docs/howto/deployment/index.txt
Log:
Fixed #16276 -- Noted in the deployment documentation index that the Django 
Book 2nd ed. was written against Django 1.1. Thanks to bshaurette and 
bluejeansummer for the patch.

Modified: django/trunk/docs/howto/deployment/index.txt
===
--- django/trunk/docs/howto/deployment/index.txt2011-09-11 01:01:58 UTC 
(rev 16801)
+++ django/trunk/docs/howto/deployment/index.txt2011-09-11 01:12:11 UTC 
(rev 16802)
@@ -20,8 +20,9 @@
 
 .. seealso::
 
-* `Chapter 12 of the Django Book`_ discusses deployment and especially
-  scaling in more detail. However, it hasn't been updated since mod_python
-  was deprecated.
+* `Chapter 12 of the Django Book (second edition)`_ discusses deployment
+  and especially scaling in more detail. However, note that this edition
+  was written against Django version 1.1 and has not been updated since
+  :doc:`mod_python ` was deprecated.
 
-.. _chapter 12 of the django book: http://djangobook.com/en/2.0/chapter12/
+.. _chapter 12 of the django book (second edition): 
http://djangobook.com/en/2.0/chapter12/

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16276: Django 1.3 docs referring users to outdated version of Django Book

[Django]

#16276: Django 1.3 docs referring users to outdated version of Django Book
-+-
   Reporter:  anonymous  |  Owner:  bshaurette
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 In [16802]:
 {{{
 #!CommitTicketReference repository="" revision="16802"
 Fixed #16276 -- Noted in the deployment documentation index that the
 Django Book 2nd ed. was written against Django 1.1. Thanks to bshaurette
 and bluejeansummer for 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15516: Update the ticket life cycle diagram

[Django]

#15516: Update the ticket life cycle diagram
-+-
   Reporter:  ramiro |  Owner:  tswicegood
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by tswicegood):

 I've talked with Idan about this.  It spun off a whole long discussion
 about what this lifecycle should be, so by the time someone gets around to
 reviewing it, this could very well be irrelevant. :-)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16804: Problem with Django 1.2.6 - Patch isn't in online tar.gz

[Django]

#16804: Problem with Django 1.2.6 - Patch isn't in online tar.gz
+-
   Reporter:  Stephane  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Uncategorized
Version:  1.2   |   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 ubernostrum):

 In [16801]:
 {{{
 #!CommitTicketReference repository="" revision="16801"
 [1.2.X] Bump to 1.2.7, refs #16804.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16801 - in django/branches/releases/1.2.X: . django docs

[noreply]

Author: ubernostrum
Date: 2011-09-10 18:01:58 -0700 (Sat, 10 Sep 2011)
New Revision: 16801

Modified:
   django/branches/releases/1.2.X/django/__init__.py
   django/branches/releases/1.2.X/docs/conf.py
   django/branches/releases/1.2.X/setup.py
Log:
[1.2.X] Bump to 1.2.7, refs #16804.

Modified: django/branches/releases/1.2.X/django/__init__.py
===
--- django/branches/releases/1.2.X/django/__init__.py   2011-09-11 00:52:08 UTC 
(rev 16800)
+++ django/branches/releases/1.2.X/django/__init__.py   2011-09-11 01:01:58 UTC 
(rev 16801)
@@ -1,4 +1,4 @@
-VERSION = (1, 2, 6, 'final', 0)
+VERSION = (1, 2, 7, 'final', 0)
 
 def get_version():
 version = '%s.%s' % (VERSION[0], VERSION[1])

Modified: django/branches/releases/1.2.X/docs/conf.py
===
--- django/branches/releases/1.2.X/docs/conf.py 2011-09-11 00:52:08 UTC (rev 
16800)
+++ django/branches/releases/1.2.X/docs/conf.py 2011-09-11 01:01:58 UTC (rev 
16801)
@@ -52,7 +52,7 @@
 # The short X.Y version.
 version = '1.2'
 # The full version, including alpha/beta/rc tags.
-release = '1.2.6'
+release = '1.2.7'
 # The next version to be released
 django_next_version = '1.3'
 

Modified: django/branches/releases/1.2.X/setup.py
===
--- django/branches/releases/1.2.X/setup.py 2011-09-11 00:52:08 UTC (rev 
16800)
+++ django/branches/releases/1.2.X/setup.py 2011-09-11 01:01:58 UTC (rev 
16801)
@@ -77,7 +77,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'http://media.djangoproject.com/releases/1.2/Django-1.2.6.tar.gz',
+download_url = 
'http://media.djangoproject.com/releases/1.2/Django-1.2.7.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5968: Registering/Unregistering multiple models fails

[Django]

#5968: Registering/Unregistering multiple models fails
-+-
   Reporter:  anderso|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jamesp):

 * ui_ux:   => 0


Comment:

 Updated to trunk@[16797] and added tests (I hope checking to ensure models
 were correctly added to {{{databrowse.site.registry}}} is adequate).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16803: Unicode representation of ContentType instances is not translated

[Django]

#16803: Unicode representation of ContentType instances is not translated
-+-
   Reporter:  bronger|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  1.3|  contrib.contenttypes
 Resolution: |   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  |
-+-

Comment (by bronger):

 I have three occurences of M2M relationships to !ContentType in my models.
 These models become model forms.  Then, you get selection boxes in the
 browser with untranslated items.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16800 - in django/trunk: . django/contrib/gis/db/backends/spatialite django/contrib/gis/tests/geoapp docs/ref/contrib/gis

[noreply]

Author: jbronn
Date: 2011-09-10 17:52:08 -0700 (Sat, 10 Sep 2011)
New Revision: 16800

Modified:
   django/trunk/AUTHORS
   django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
   django/trunk/django/contrib/gis/tests/geoapp/tests.py
   django/trunk/docs/ref/contrib/gis/db-api.txt
   django/trunk/docs/ref/contrib/gis/geoquerysets.txt
Log:
Fixed #16231 -- Added support for GML and KML on the SpatiaLite backend.  
Thanks, steko for the bug report and jpaulett for the patch.

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2011-09-11 00:52:03 UTC (rev 16799)
+++ django/trunk/AUTHORS2011-09-11 00:52:08 UTC (rev 16800)
@@ -393,6 +393,7 @@
 Jay Parlar 
 Claude Paroz 
 Carlos Eduardo de Paula 
+John Paulett 
 pavithran s 
 Barry Pederson 
 Andreas Pelme 

Modified: django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-09-11 00:52:03 UTC (rev 16799)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-09-11 00:52:08 UTC (rev 16800)
@@ -133,6 +133,18 @@
 gis_terms += self.geometry_functions.keys()
 self.gis_terms = dict([(term, None) for term in gis_terms])
 
+if version >= (2, 4, 0):
+# Spatialite 2.4.0-RC4 added AsGML and AsKML, however both
+# RC2 (shipped in popular Debian/Ubuntu packages) and RC4
+# report version as '2.4.0', so we fall back to feature detection
+try:
+self._get_spatialite_func("AsGML(GeomFromText('POINT(1 1)'))")
+self.gml = 'AsGML'
+self.kml = 'AsKML'
+except DatabaseError:
+# we are using < 2.4.0-RC4
+pass
+
 def check_aggregate_support(self, aggregate):
 """
 Checks if the given aggregate name is supported (that is, if it's

Modified: django/trunk/django/contrib/gis/tests/geoapp/tests.py
===
--- django/trunk/django/contrib/gis/tests/geoapp/tests.py   2011-09-11 
00:52:03 UTC (rev 16799)
+++ django/trunk/django/contrib/gis/tests/geoapp/tests.py   2011-09-11 
00:52:08 UTC (rev 16800)
@@ -1,5 +1,6 @@
 import re
 from django.db import connection
+from django.db.utils import DatabaseError
 from django.contrib.gis import gdal
 from django.contrib.gis.geos import (fromstr, GEOSGeometry,
 Point, LineString, LinearRing, Polygon, GeometryCollection)
@@ -92,8 +93,8 @@
 
 def test03a_kml(self):
 "Testing KML output from the database using GeoQuerySet.kml()."
-# Only PostGIS supports KML serialization
-if not postgis:
+# Only PostGIS and Spatialite (>=2.4.0-RC4) support KML serialization
+if not (postgis or (spatialite and connection.ops.kml)):
 self.assertRaises(NotImplementedError, State.objects.all().kml, 
field_name='poly')
 return
 
@@ -117,7 +118,7 @@
 
 def test03b_gml(self):
 "Testing GML output from the database using GeoQuerySet.gml()."
-if mysql or spatialite:
+if mysql or (spatialite and not connection.ops.gml) :
 self.assertRaises(NotImplementedError, Country.objects.all().gml, 
field_name='mpoly')
 return
 
@@ -131,13 +132,16 @@
 if oracle:
 # No precision parameter for Oracle :-/
 gml_regex = re.compile(r'^http://www.opengis.net/gml";>-104.60925\d+,38.25500\d+ ')
-for ptown in [ptown1, ptown2]:
-self.assertTrue(gml_regex.match(ptown.gml))
+elif spatialite:
+# Spatialite has extra colon in SrsName
+gml_regex = re.compile(r'^-104.609251\d+,38.255001')
 else:
 gml_regex = re.compile(r'^-104\.60925\d+,38\.255001')
-for ptown in [ptown1, ptown2]:
-self.assertTrue(gml_regex.match(ptown.gml))
 
+for ptown in [ptown1, ptown2]:
+self.assertTrue(gml_regex.match(ptown.gml))
+
+
 def test03c_geojson(self):
 "Testing GeoJSON output from the database using GeoQuerySet.geojson()."
 # Only PostGIS 1.3.4+ supports GeoJSON.

Modified: django/trunk/docs/ref/contrib/gis/db-api.txt
===
--- django/trunk/docs/ref/contrib/gis/db-api.txt2011-09-11 00:52:03 UTC 
(rev 16799)
+++ django/trunk/docs/ref/contrib/gis/db-api.txt2011-09-11 00:52:08 UTC 
(rev 16800)
@@ -287,9 +287,9 @@
 :meth:`GeoQuerySet.force_rhr` X
 :meth:`GeoQuerySet.geohash`   X
 :meth:`GeoQuerySet.geojson`   X
-:meth:`GeoQuerySet.gml`   XX
+:meth:`GeoQuerySet.gml`   XX   X
 :meth:`GeoQuerySet.intersection`  XX   

Re: [Django] #16231: add support for AsGML() and AsKML() for the Spatialite backend

[Django]

#16231: add support for AsGML() and AsKML() for the Spatialite backend
---+
   Reporter:  steko|  Owner:  steko
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  GIS
Version:  1.3  |   Severity:  Normal
 Resolution:  fixed|   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 jbronn):

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


Comment:

 In [16800]:
 {{{
 #!CommitTicketReference repository="" revision="16800"
 Fixed #16231 -- Added support for GML and KML on the SpatiaLite backend.
 Thanks, steko for the bug report and jpaulett for 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14138: Apache setup using sqlite3 breaks when performing a field__regex filter

[Django]

#14138: Apache setup using sqlite3 breaks when performing a field__regex filter
-+-
   Reporter: |  Owner:  nobody
  eternicode | Status:  closed
   Type: |  Component:  Database layer
  Uncategorized  |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  sqlite3 apache
 Resolution:  fixed  |  operationalerror databaseerror
   Triage Stage:  Accepted   |  regex
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by ramiro):

 * resolution:  worksforme => fixed


Comment:

 In [16799]:
 {{{
 #!CommitTicketReference repository="" revision="16799"
 Fixed #14138 -- Removed a superfluous import in the sqlite3 DB backend.

 This could be of help with some issues people were seeing when deploying
 Django with sqlite and Apache.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16799 - django/trunk/django/db/backends/sqlite3

[noreply]

Author: ramiro
Date: 2011-09-10 17:52:03 -0700 (Sat, 10 Sep 2011)
New Revision: 16799

Modified:
   django/trunk/django/db/backends/sqlite3/base.py
Log:
Fixed #14138 -- Removed a superfluous import in the sqlite3 DB backend.

This could be of help with some issues people were seeing when deploying
Django with sqlite and Apache.

Modified: django/trunk/django/db/backends/sqlite3/base.py
===
--- django/trunk/django/db/backends/sqlite3/base.py 2011-09-11 00:15:43 UTC 
(rev 16798)
+++ django/trunk/django/db/backends/sqlite3/base.py 2011-09-11 00:52:03 UTC 
(rev 16799)
@@ -330,7 +330,6 @@
 return rv
 
 def _sqlite_regexp(re_pattern, re_string):
-import re
 try:
 return bool(re.search(re_pattern, re_string))
 except:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15295: GeoDjango model creation fails for MySQL during tests

[Django]

#15295: GeoDjango model creation fails for MySQL during tests
--+
   Reporter:  adamnelson  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  GIS
Version:  SVN |   Severity:  Normal
 Resolution:  wontfix |   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 jbronn):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 !GeoDjango is not supported on MySQL when InnoDB is used.  If you want the
 tests to pass, ensure the correct options are in your settings when
 testing, for example:
 {{{
 #!python
 TEST_RUNNER='django.contrib.gis.tests.GeoDjangoTestSuiteRunner'

 DATABASES = {
 'default': {
 'ENGINE': 'django.contrib.gis.db.backends.mysql',
 'NAME': 'geodjango',
 'USER': 'geodjango',
 'OPTIONS': {
 'init_command': 'SET storage_engine=MyISAM',
 }
 },
 }
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
---+---
   Reporter:  lrekucki |  Owner:  lrekucki
   Type:  New feature  | Status:  reopened
  Milestone:  1.4  |  Component:  Generic views
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  class-based-views
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by roalddevries):

 * type:  Uncategorized => New feature
 * milestone:  1.3 => 1.4


Comment:

 I attached a patch that does the job. It uses a copy of the original class
 instead of a subclass, which resolves the infinite recursion. The patch is
 made wrt django 1.3.1 (not trunk).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5970: ChangeList.get_query_set() method ignores specified by model's admin manager QuerySet for search_fields lookup

[Django]

#5970: ChangeList.get_query_set() method ignores specified by model's admin
manager QuerySet for search_fields lookup
-+-
   Reporter:  Nazar  |  Owner:  nobody
  <911.17@…> | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  search_fields
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => fixed
 * easy:   => 0


Comment:

 This was fixed at some point.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13429: GeoDjango tutorial model should be WorldBorder(singular) instead of WorldBorders(plural)

[Django]

#13429: GeoDjango tutorial model should be WorldBorder(singular) instead of
WorldBorders(plural)
+--
   Reporter:  tubaman   |Owner:  jbronn
   Type:  Bug   |   Status:  closed
  Milestone:|Component:  GIS
Version:  SVN   | Severity:  Normal
 Resolution:  fixed | Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+--
Changes (by jbronn):

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


Comment:

 In [16798]:
 {{{
 #!CommitTicketReference repository="" revision="16798"
 Fixed #13429 -- Changed `WorldBorders` to just `WorldBorder` in GeoDjango
 tutorial.  Thanks, tubaman for the bug report.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16798 - django/trunk/docs/ref/contrib/gis

[noreply]

Author: jbronn
Date: 2011-09-10 17:15:43 -0700 (Sat, 10 Sep 2011)
New Revision: 16798

Modified:
   django/trunk/docs/ref/contrib/gis/geoquerysets.txt
   django/trunk/docs/ref/contrib/gis/tutorial.txt
Log:
Fixed #13429 -- Changed `WorldBorders` to just `WorldBorder` in GeoDjango 
tutorial.  Thanks, tubaman for the bug report.

Modified: django/trunk/docs/ref/contrib/gis/geoquerysets.txt
===
--- django/trunk/docs/ref/contrib/gis/geoquerysets.txt  2011-09-11 00:00:15 UTC 
(rev 16797)
+++ django/trunk/docs/ref/contrib/gis/geoquerysets.txt  2011-09-11 00:15:43 UTC 
(rev 16798)
@@ -1203,7 +1203,7 @@
 Example::
 
 >>> from django.contrib.gis.db.models import Extent, Union
->>> WorldBorders.objects.aggregate(Extent('mpoly'), Union('mpoly'))
+>>> WorldBorder.objects.aggregate(Extent('mpoly'), Union('mpoly'))
 
 ``Collect``
 ~~~

Modified: django/trunk/docs/ref/contrib/gis/tutorial.txt
===
--- django/trunk/docs/ref/contrib/gis/tutorial.txt  2011-09-11 00:00:15 UTC 
(rev 16797)
+++ django/trunk/docs/ref/contrib/gis/tutorial.txt  2011-09-11 00:15:43 UTC 
(rev 16798)
@@ -212,7 +212,7 @@
 
 from django.contrib.gis.db import models
 
-class WorldBorders(models.Model):
+class WorldBorder(models.Model):
 # Regular Django fields corresponding to the attributes in the
# world borders shapefile.
 name = models.CharField(max_length=50)
@@ -232,10 +232,6 @@
mpoly = models.MultiPolygonField()
objects = models.GeoManager()
 
-# So the model is pluralized correctly in the admin.
-class Meta:
-verbose_name_plural = "World Borders"
-
 # Returns the string representation of the model.
 def __unicode__(self):
 return self.name
@@ -259,7 +255,7 @@
 --
 
 After you've defined your model, it needs to be synced with the spatial 
database.
-First, let's look at the SQL that will generate the table for the 
``WorldBorders``
+First, let's look at the SQL that will generate the table for the 
``WorldBorder``
 model::
 
 $ python manage.py sqlall world
@@ -292,7 +288,7 @@
 
 $ python manage.py syncdb
 Creating table world_worldborders
-Installing custom SQL for world.WorldBorders model
+Installing custom SQL for world.WorldBorder model
 
 The ``syncdb`` command may also prompt you to create an admin user; go ahead 
and
 do so (not required now, may be done at any point in the future using the
@@ -445,7 +441,7 @@
 
 import os
 from django.contrib.gis.utils import LayerMapping
-from models import WorldBorders
+from models import WorldBorder
 
 world_mapping = {
 'fips' : 'FIPS',
@@ -465,7 +461,7 @@
 world_shp = os.path.abspath(os.path.join(os.path.dirname(__file__), 
'data/TM_WORLD_BORDERS-0.3.shp'))
 
 def run(verbose=True):
-lm = LayerMapping(WorldBorders, world_shp, world_mapping,
+lm = LayerMapping(WorldBorder, world_shp, world_mapping,
   transform=False, encoding='iso-8859-1')
 
 lm.save(strict=True, verbose=verbose)
@@ -473,7 +469,7 @@
 A few notes about what's going on:
 
 * Each key in the ``world_mapping`` dictionary corresponds to a field in the
-  ``WorldBorders`` model, and the value is the name of the shapefile field
+  ``WorldBorder`` model, and the value is the name of the shapefile field
   that data will be loaded from.
 * The key ``mpoly`` for the geometry field is ``MULTIPOLYGON``, the
   geometry type we wish to import as.  Even if simple polygons are encountered
@@ -517,10 +513,10 @@
 ``model_name`` is the name to use for the model.  Command-line options may
 be used to further define how the model is generated.
 
-For example, the following command nearly reproduces the ``WorldBorders`` model
+For example, the following command nearly reproduces the ``WorldBorder`` model
 and mapping dictionary created above, automatically::
 
-$ python manage.py ogrinspect world/data/TM_WORLD_BORDERS-0.3.shp 
WorldBorders --srid=4326 --mapping --multi
+$ python manage.py ogrinspect world/data/TM_WORLD_BORDERS-0.3.shp 
WorldBorder --srid=4326 --mapping --multi
 
 A few notes about the command-line options given above:
 
@@ -537,7 +533,7 @@
 # This is an auto-generated Django model module created by ogrinspect.
 from django.contrib.gis.db import models
 
-class WorldBorders(models.Model):
+class WorldBorder(models.Model):
 fips = models.CharField(max_length=2)
 iso2 = models.CharField(max_length=2)
 iso3 = models.CharField(max_length=3)
@@ -552,7 +548,7 @@
 geom = models.MultiPolygonField(srid=4326)
 objects = models.GeoManager()
 
-# Auto-generated `LayerMapping` dictionary for WorldBorders model
+# Auto-generated `LayerMapping` dictionary for WorldBorder model
 worldborders_mapping = {

Re: [Django] #5964: utils: urlunquote

[Django]

#5964: utils: urlunquote
-+-
   Reporter:  Thomas |  Owner:  nobody
  Güttler (Home) < > | Status:  new
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Alex):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5936: django-admin's shell --plain command doesn't respect PYTHONSTARTUP or .pythonrc settings

[Django]

#5936: django-admin's shell --plain command doesn't respect PYTHONSTARTUP or
.pythonrc settings
--+--
   Reporter:  toddobryan  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Core (Other)
Version:  SVN |   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 carljm):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Given that that "django-admin.py help shell" describes --plain simply as
 "use plain Python, not IPython", and plain Python normally would respect
 .pythonrc and PYTHONSTARTUP, it does seem like this ought to be changed so
 --plain still loads those files.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16797 - in django/trunk/django/contrib/gis: db/models/sql tests/relatedapp

[noreply]

Author: jbronn
Date: 2011-09-10 17:00:15 -0700 (Sat, 10 Sep 2011)
New Revision: 16797

Modified:
   django/trunk/django/contrib/gis/db/models/sql/compiler.py
   django/trunk/django/contrib/gis/tests/relatedapp/tests.py
Log:
Fixed #15305 -- Made `Count` aggregate and `.values()` play nice together on 
`GeoQuerySets`.  Thanks, vrehak for the bug report and milosu for initial patch.

Modified: django/trunk/django/contrib/gis/db/models/sql/compiler.py
===
--- django/trunk/django/contrib/gis/db/models/sql/compiler.py   2011-09-10 
22:53:26 UTC (rev 16796)
+++ django/trunk/django/contrib/gis/db/models/sql/compiler.py   2011-09-11 
00:00:15 UTC (rev 16797)
@@ -171,10 +171,6 @@
 """
 values = []
 aliases = self.query.extra_select.keys()
-if self.query.aggregates:
-# If we have an aggregate annotation, must extend the aliases
-# so their corresponding row values are included.
-aliases.extend([None for i in xrange(len(self.query.aggregates))])
 
 # Have to set a starting row number offset that is used for
 # determining the correct starting row index -- needed for

Modified: django/trunk/django/contrib/gis/tests/relatedapp/tests.py
===
--- django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2011-09-10 
22:53:26 UTC (rev 16796)
+++ django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2011-09-11 
00:00:15 UTC (rev 16797)
@@ -245,6 +245,13 @@
 self.assertEqual(1, len(vqs))
 self.assertEqual(3, vqs[0]['num_books'])
 
+def test13c_count(self):
+"Testing `Count` aggregate with `.values()`.  See #15305."
+qs = 
Location.objects.filter(id=5).annotate(num_cities=Count('city')).values('id', 
'point', 'num_cities')
+self.assertEqual(1, len(qs))
+self.assertEqual(2, qs[0]['num_cities'])
+self.assertTrue(isinstance(qs[0]['point'], GEOSGeometry))
+
 # TODO: The phantom model does appear on Oracle.
 @no_oracle
 def test13_select_related_null_fk(self):
@@ -284,7 +291,7 @@
 
 def test16_annotated_date_queryset(self):
 "Ensure annotated date querysets work if spatial backend is used.  See 
#14648."
-birth_years = [dt.year for dt in 
+birth_years = [dt.year for dt in

list(Author.objects.annotate(num_books=Count('books')).dates('dob', 'year'))]
 birth_years.sort()
 self.assertEqual([1950, 1974], birth_years)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15305: GeoQuerySet with values() and aggregates raises exception

[Django]

#15305: GeoQuerySet with values() and aggregates raises exception
+
   Reporter:  vrehak|  Owner:  jbronn
   Type:  Bug   | Status:  closed
  Milestone:  1.4   |  Component:  GIS
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   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 jbronn):

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


Comment:

 In [16797]:
 {{{
 #!CommitTicketReference repository="" revision="16797"
 Fixed #15305 -- Made `Count` aggregate and `.values()` play nice together
 on `GeoQuerySets`.  Thanks, vrehak for the bug report and milosu for
 initial 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5908: Cycle tag should reset after it steps out of scope(?)

[Django]

#5908: Cycle tag should reset after it steps out of scope(?)
-+-
   Reporter:  Simon  |  Owner:  nobody
  Litchfield| Status:  new
   Type: |  Component:  Template system
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  cycle templatetag
Version:  SVN|  tag counter for loop reset
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jamesp):

 * ui_ux:   => 0


Comment:

 Updated the patch to the current trunk but I am wondering if {{{ {%
 resetcycle %} }}} shouldn't reset the most recent cycle if a name isn't
 provided.
 This would be consistent with {{{ {% endblock %} }}} and may lead to
 confusion if not implemented similarly.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5865: cycle template tag should accept a single argument

[Django]

#5865: cycle template tag should accept a single argument
---+-
   Reporter:  gwilson  |  Owner:  munhitsu
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Template system
Version:  SVN  |   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 Alex):

 * ui_ux:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Discussion with Carl: this new syntax would be ambiguous with the current
 syntax, however this is a good feature, and the current API is kind of
 silly.  This is accepted, provisional on creating a new, more sane and
 consistent syntax, to be placed in the future module.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5897: Add Content-Length header in common middleware

[Django]

#5897: Add Content-Length header in common middleware
-+-
   Reporter:  Scott  |  Owner:  ccahoon
  Barr  | Status:  closed
   Type:  New|  Component:  HTTP handling
  feature|   Severity:  Normal
  Milestone: |   Keywords:  Content-Length
Version:  SVN|  middleware
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Discussion with Alex at sprint: since this is not required by spec, and is
 already available in ConditionalGetMiddleware for those who want it, we
 don't want to go exhausting iterator responses by default in
 CommonMiddleware.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15633: Bad documentation of post_syncdb signal

[Django]

#15633: Bad documentation of post_syncdb signal
+---
   Reporter:  vzima |  Owner:  justinlilly
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Documentation
Version:  SVN   |   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 anonymous):

 * has_patch:  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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16770: Don't wrap exceptions in TemplateSyntaxError under DEBUG

[Django]

#16770: Don't wrap exceptions in TemplateSyntaxError under DEBUG
+-
   Reporter:  jMyles|  Owner:  jMyles
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  1.3   |   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 jMyles):

 The corrections I made in unwrap_templatesyntaxerror-3.diff are also in
 the github - it's now the authoritative version of this patch:
 https://github.com/carljm/django/compare/master...t16770

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5763: Queryset doesn't have a "not equal" filter operator

[Django]

#5763: Queryset doesn't have a "not equal" filter operator
-+-
   Reporter:  jdetaeye   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  wontfix|   Keywords:  qs-rf
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  reopened => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Based on discussion with Alex and Andrew at the sprint, closing this
 wontfix on the basis that it doesn't make sense to have `__ne` without any
 other negated queries, when we already have .exclude() to express
 negatives.

 Alex promises that he really will fix the SQL generation to not be stupid
 with .exclude().

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5681: Save as new disappears on failed validation

[Django]

#5681: Save as new disappears on failed validation
-+-
   Reporter:  Uninen |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.admin
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  admin, save
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by carljm):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => fixed
 * easy:   => 0


Comment:

 On the basis of ramiro's comment, closing this as fixed, since the real
 problem is that a new object was not created. Otherwise, existing behavior
 seems reasonable.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5373: Field label for a ForeignKey not translated

[Django]

#5373: Field label for a ForeignKey not translated
-+-
   Reporter: |  Owner:  garcia_marc
  Szilveszter Farkas | Status:  new
   |  Component:
   Type:  Bug|  Internationalization
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  i18n foreignkey
 Resolution: |  field label
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 This doesn't look like DDN, just a matter of reviewing the patch and
 making some implementation decisions. The ticket is a bug that needs to be
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2550: [patch] Allow a Backend to Globally Fail Authentication

[Django]

#2550: [patch] Allow a Backend to Globally Fail Authentication
-+-
   Reporter:  umbrae@…   |  Owner:  aashu_dwivedi
   Type:  New| Status:  new
  feature|  Component:  contrib.auth
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  authentication
 Resolution: |  backends easy-pickings
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by carljm):

 * stage:  Design decision needed => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #2259: Primary keys should be readonly by default in admin (was: PK Change creates new object instead of update)

[Django]

#2259: Primary keys should be readonly by default in admin
+---
   Reporter:  ed@…  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:|   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by carljm):

 * stage:  Design decision needed => Accepted


Comment:

 In discussion with Alex at the sprint, the need for cascading updates of
 foreign keys pushes this beyond the bounds of what's reasonable for Django
 to try to support. Primary keys should not change.

 We should, however, update the admin so that primary key fields are
 included in readonly_fields by default, to avoid the confusing and
 unexpected creation of new records.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14648: Annotated date querysets fail if spatial backend is used

[Django]

#14648: Annotated date querysets fail if spatial backend is used
---+--
   Reporter:  codysoyland  |Owner:  jbronn
   Type:  Bug  |   Status:  closed
  Milestone:   |Component:  GIS
Version:  1.2  | Severity:  Normal
 Resolution:  fixed| Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  1
Patch needs improvement:  1|
---+--
Changes (by jbronn):

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


Comment:

 In [16796]:
 {{{
 #!CommitTicketReference repository="" revision="16796"
 Fixed #14648 -- Fixed annotated date querysets when `GeoManager` is used.
 Thanks, codysoyland, for the bug report.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16796 - in django/trunk/django/contrib/gis: db/backends/spatialite db/models/sql tests/relatedapp tests/relatedapp/fixtures

[noreply]

Author: jbronn
Date: 2011-09-10 15:53:26 -0700 (Sat, 10 Sep 2011)
New Revision: 16796

Removed:
   django/trunk/django/contrib/gis/db/backends/spatialite/compiler.py
Modified:
   django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
   django/trunk/django/contrib/gis/db/models/sql/compiler.py
   
django/trunk/django/contrib/gis/tests/relatedapp/fixtures/initial_data.json.gz
   django/trunk/django/contrib/gis/tests/relatedapp/models.py
   django/trunk/django/contrib/gis/tests/relatedapp/tests.py
Log:
Fixed #14648 -- Fixed annotated date querysets when `GeoManager` is used.  
Thanks, codysoyland, for the bug report.

Deleted: django/trunk/django/contrib/gis/db/backends/spatialite/compiler.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/compiler.py  
2011-09-10 22:46:44 UTC (rev 16795)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/compiler.py  
2011-09-10 22:53:26 UTC (rev 16796)
@@ -1,32 +0,0 @@
-from django.db.backends.util import typecast_timestamp
-from django.db.models.sql import compiler
-from django.db.models.sql.constants import MULTI
-from django.contrib.gis.db.models.sql.compiler import GeoSQLCompiler as 
BaseGeoSQLCompiler
-
-SQLCompiler = compiler.SQLCompiler
-
-class GeoSQLCompiler(BaseGeoSQLCompiler, SQLCompiler):
-pass
-
-class SQLInsertCompiler(compiler.SQLInsertCompiler, GeoSQLCompiler):
-pass
-
-class SQLDeleteCompiler(compiler.SQLDeleteCompiler, GeoSQLCompiler):
-pass
-
-class SQLUpdateCompiler(compiler.SQLUpdateCompiler, GeoSQLCompiler):
-pass
-
-class SQLAggregateCompiler(compiler.SQLAggregateCompiler, GeoSQLCompiler):
-pass
-
-class SQLDateCompiler(compiler.SQLDateCompiler, GeoSQLCompiler):
-"""
-This is overridden for GeoDjango to properly cast date columns, see #16757.
-"""
-def results_iter(self):
-offset = len(self.query.extra_select)
-for rows in self.execute_sql(MULTI):
-for row in rows:
-date = typecast_timestamp(str(row[offset]))
-yield date

Modified: django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-09-10 22:46:44 UTC (rev 16795)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-09-10 22:53:26 UTC (rev 16796)
@@ -48,7 +48,7 @@
 return (SpatiaLiteDistance(operator),)
 
 class SpatiaLiteOperations(DatabaseOperations, BaseSpatialOperations):
-compiler_module = 'django.contrib.gis.db.backends.spatialite.compiler'
+compiler_module = 'django.contrib.gis.db.models.sql.compiler'
 name = 'spatialite'
 spatialite = True
 version_regex = 
re.compile(r'^(?P\d)\.(?P\d)\.(?P\d+)')

Modified: django/trunk/django/contrib/gis/db/models/sql/compiler.py
===
--- django/trunk/django/contrib/gis/db/models/sql/compiler.py   2011-09-10 
22:46:44 UTC (rev 16795)
+++ django/trunk/django/contrib/gis/db/models/sql/compiler.py   2011-09-10 
22:53:26 UTC (rev 16796)
@@ -1,7 +1,7 @@
 from itertools import izip
-from django.db.backends.util import truncate_name
+from django.db.backends.util import truncate_name, typecast_timestamp
 from django.db.models.sql import compiler
-from django.db.models.sql.constants import TABLE_NAME
+from django.db.models.sql.constants import TABLE_NAME, MULTI
 from django.db.models.sql.query import get_proxied_model
 
 SQLCompiler = compiler.SQLCompiler
@@ -194,7 +194,7 @@
 # We resolve the rest of the columns if we're on Oracle or if
 # the `geo_values` attribute is defined.
 for value, field in map(None, row[index_start:], fields):
-values.append(self.query.convert_values(value, field, 
connection=self.connection))
+values.append(self.query.convert_values(value, field, 
self.connection))
 else:
 values.extend(row[index_start:])
 return tuple(values)
@@ -275,4 +275,24 @@
 pass
 
 class SQLDateCompiler(compiler.SQLDateCompiler, GeoSQLCompiler):
-pass
+"""
+This is overridden for GeoDjango to properly cast date columns, since
+`GeoQuery.resolve_columns` is used for spatial values.
+See #14648, #16757.
+"""
+def results_iter(self):
+if self.connection.ops.oracle:
+from django.db.models.fields import DateTimeField
+fields = [DateTimeField()]
+else:
+needs_string_cast = 
self.connection.features.needs_datetime_string_cast
+
+offset = len(self.query.extra_select)
+for rows in self.execute_sql(MULTI):
+for row in rows:
+date = row[offset]
+if self.connection.ops.oracle:
+date = self.resolve_columns(row, fields)[offset]
+el

[Changeset] r16795 - in django/trunk/django: core core/handlers core/management core/management/commands template

[noreply]

Author: Alex
Date: 2011-09-10 15:46:44 -0700 (Sat, 10 Sep 2011)
New Revision: 16795

Modified:
   django/trunk/django/core/handlers/base.py
   django/trunk/django/core/management/__init__.py
   django/trunk/django/core/management/commands/dumpdata.py
   django/trunk/django/core/management/commands/shell.py
   django/trunk/django/core/management/sql.py
   django/trunk/django/core/validators.py
   django/trunk/django/template/defaultfilters.py
   django/trunk/django/template/defaulttags.py
Log:
Kill some more dead code.

Modified: django/trunk/django/core/handlers/base.py
===
--- django/trunk/django/core/handlers/base.py   2011-09-10 22:31:38 UTC (rev 
16794)
+++ django/trunk/django/core/handlers/base.py   2011-09-10 22:46:44 UTC (rev 
16795)
@@ -152,7 +152,7 @@
 try:
 response = self.handle_uncaught_exception(request, 
resolver, sys.exc_info())
 finally:
-receivers = 
signals.got_request_exception.send(sender=self.__class__, request=request)
+
signals.got_request_exception.send(sender=self.__class__, request=request)
 except exceptions.PermissionDenied:
 logger.warning(
 'Forbidden (Permission denied): %s' % request.path,
@@ -168,14 +168,14 @@
 response = self.handle_uncaught_exception(request,
 resolver, sys.exc_info())
 finally:
-receivers = signals.got_request_exception.send(
+signals.got_request_exception.send(
 sender=self.__class__, request=request)
 except SystemExit:
 # Allow sys.exit() to actually exit. See tickets #1023 and 
#4701
 raise
 except: # Handle everything else, including SuspiciousOperation, 
etc.
 # Get the exception info now, in case another exception is 
thrown later.
-receivers = 
signals.got_request_exception.send(sender=self.__class__, request=request)
+signals.got_request_exception.send(sender=self.__class__, 
request=request)
 response = self.handle_uncaught_exception(request, resolver, 
sys.exc_info())
 finally:
 # Reset URLconf for this thread on the way out for complete
@@ -188,7 +188,7 @@
 response = middleware_method(request, response)
 response = self.apply_response_fixes(request, response)
 except: # Any exception should be gathered and handled
-receivers = 
signals.got_request_exception.send(sender=self.__class__, request=request)
+signals.got_request_exception.send(sender=self.__class__, 
request=request)
 response = self.handle_uncaught_exception(request, resolver, 
sys.exc_info())
 
 return response

Modified: django/trunk/django/core/management/__init__.py
===
--- django/trunk/django/core/management/__init__.py 2011-09-10 22:31:38 UTC 
(rev 16794)
+++ django/trunk/django/core/management/__init__.py 2011-09-10 22:46:44 UTC 
(rev 16795)
@@ -420,7 +420,7 @@
 # Import the project module. We add the parent directory to PYTHONPATH to
 # avoid some of the path errors new users can have.
 sys.path.append(os.path.join(project_directory, os.pardir))
-project_module = import_module(project_name)
+import_module(project_name)
 sys.path.pop()
 
 return project_directory

Modified: django/trunk/django/core/management/commands/dumpdata.py
===
--- django/trunk/django/core/management/commands/dumpdata.py2011-09-10 
22:31:38 UTC (rev 16794)
+++ django/trunk/django/core/management/commands/dumpdata.py2011-09-10 
22:46:44 UTC (rev 16795)
@@ -1,7 +1,7 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.core.management.base import BaseCommand, CommandError
 from django.core import serializers
-from django.db import connections, router, DEFAULT_DB_ALIAS
+from django.db import router, DEFAULT_DB_ALIAS
 from django.utils.datastructures import SortedDict
 
 from optparse import make_option
@@ -28,12 +28,11 @@
 args = '[appname appname.ModelName ...]'
 
 def handle(self, *app_labels, **options):
-from django.db.models import get_app, get_apps, get_models, get_model
+from django.db.models import get_app, get_apps, get_model
 
 format = options.get('format','json')
 indent = options.get('indent',None)
 using = options.get('database', DEFAULT_DB_ALIAS)
-connection = connections[using]
 excludes = options.get('exclude',[])
 show_traceback = options.get('traceback', False)
 use_natural_keys = options.get('use_natural_keys', False)

Re: [Django] #16807: Document/Introduce the process and usage of class based views outside of generic view context

[Django]

#16807: Document/Introduce the process and usage of class based views outside of
generic view context
---+---
   Reporter:  ptone|  Owner:  ptone
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Documentation
Version:  SVN  |   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 ptone):

 hopefully the documentation of decoration will also be updated via #14512

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16794 - in django/trunk/django/db: backends models models/sql

[noreply]

Author: Alex
Date: 2011-09-10 15:31:38 -0700 (Sat, 10 Sep 2011)
New Revision: 16794

Modified:
   django/trunk/django/db/backends/creation.py
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/query.py
   django/trunk/django/db/models/sql/compiler.py
   django/trunk/django/db/models/sql/query.py
Log:
Remove a bunch of deadcode/dead imports.

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2011-09-10 22:02:13 UTC (rev 
16793)
+++ django/trunk/django/db/backends/creation.py 2011-09-10 22:31:38 UTC (rev 
16794)
@@ -61,7 +61,7 @@
 if f.rel:
 ref_output, pending = 
self.sql_for_inline_foreign_key_references(f, known_models, style)
 if pending:
-pr = pending_references.setdefault(f.rel.to, 
[]).append((model, f))
+pending_references.setdefault(f.rel.to, []).append((model, 
f))
 else:
 field_output.extend(ref_output)
 table_output.append(' '.join(field_output))
@@ -267,7 +267,7 @@
 
 # Get a cursor (even though we don't need one yet). This has
 # the side effect of initializing the test database.
-cursor = self.connection.cursor()
+self.connection.cursor()
 
 return test_database_name
 

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2011-09-10 22:02:13 UTC (rev 
16793)
+++ django/trunk/django/db/models/base.py   2011-09-10 22:31:38 UTC (rev 
16794)
@@ -474,7 +474,6 @@
 ('raw', 'cls', and 'origin').
 """
 using = using or router.db_for_write(self.__class__, instance=self)
-connection = connections[using]
 assert not (force_insert and force_update)
 if cls is None:
 cls = self.__class__

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2011-09-10 22:02:13 UTC (rev 
16793)
+++ django/trunk/django/db/models/query.py  2011-09-10 22:31:38 UTC (rev 
16794)
@@ -9,7 +9,7 @@
 from django.db.models.query_utils import (Q, select_related_descend,
 deferred_class_factory, InvalidQuery)
 from django.db.models.deletion import Collector
-from django.db.models import signals, sql
+from django.db.models import sql
 from django.utils.functional import partition
 
 # Used to control how many objects are worked with at once in some cases (e.g.

Modified: django/trunk/django/db/models/sql/compiler.py
===
--- django/trunk/django/db/models/sql/compiler.py   2011-09-10 22:02:13 UTC 
(rev 16793)
+++ django/trunk/django/db/models/sql/compiler.py   2011-09-10 22:31:38 UTC 
(rev 16794)
@@ -1,14 +1,13 @@
 from itertools import izip
 
 from django.core.exceptions import FieldError
-from django.db import connections
 from django.db import transaction
 from django.db.backends.util import truncate_name
+from django.db.models.query_utils import select_related_descend
 from django.db.models.sql.constants import *
 from django.db.models.sql.datastructures import EmptyResultSet
 from django.db.models.sql.expressions import SQLEvaluator
-from django.db.models.sql.query import (get_proxied_model, get_order_dir,
- select_related_descend, Query)
+from django.db.models.sql.query import get_proxied_model, get_order_dir, Query
 from django.db.utils import DatabaseError
 
 
@@ -875,8 +874,6 @@
 Creates the SQL for this query. Returns the SQL string and list of
 parameters.
 """
-from django.db.models.base import Model
-
 self.pre_sql_setup()
 if not self.query.values:
 return '', ()

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2011-09-10 22:02:13 UTC (rev 
16793)
+++ django/trunk/django/db/models/sql/query.py  2011-09-10 22:31:38 UTC (rev 
16794)
@@ -15,7 +15,7 @@
 from django.db import connections, DEFAULT_DB_ALIAS
 from django.db.models import signals
 from django.db.models.fields import FieldDoesNotExist
-from django.db.models.query_utils import select_related_descend, InvalidQuery
+from django.db.models.query_utils import InvalidQuery
 from django.db.models.sql import aggregates as base_aggregates_module
 from django.db.models.sql.constants import *
 from django.db.models.sql.datastructures import EmptyResultSet, Empty, 
MultiJoin
@@ -567,7 +567,6 @@
 field_names, defer = self.deferred_loading
 if not field_names:
 return
-columns = set()
 orig_opts = self.model._meta
 seen = {}
 if orig_opts.proxy:

-- 
You received this message

Re: [Django] #14512: Documentation & tools for decorating class-based-views.

[Django]

#14512: Documentation & tools for decorating class-based-views.
-+-
   Reporter:  lrekucki   |  Owner:  lrekucki
   Type: | Status:  reopened
  Uncategorized  |  Component:  Generic views
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:  class-based-views
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

 * cc: preston@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.