Re: [Django] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  ccahoon
Status:  new   | Milestone:  1.2
 Component:  Core framework|   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Comment (by ccahoon):

 Replying to [comment:54 ccahoon]:
 > I have made changes for HttpResponseSendFile support, in r11266 and
 earlier commits. I am still getting used to putting the refs in my commit
 messages, but when the changes get merged with trunk it will be there. If
 you are interested, let me know what you think.

 Correction: r11268. Also, r11212 and r11210. Sorry about that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  ccahoon
Status:  new   | Milestone:  1.2
 Component:  Core framework|   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Comment (by ccahoon):

 I have made changes for HttpResponseSendFile support, in r11266 and
 earlier commits. I am still getting used to putting the refs in my commit
 messages, but when the changes get merged with trunk it will be there. If
 you are interested, let me know what you think.

-- 
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] r11268 - in django/branches/soc2009/http-wsgi-improvements: django/conf django/core/handlers django/http tests/regressiontests/sendfile

[noreply]

Author: ccahoon
Date: 2009-07-17 21:02:57 -0500 (Fri, 17 Jul 2009)
New Revision: 11268

Modified:
   django/branches/soc2009/http-wsgi-improvements/django/conf/global_settings.py
   
django/branches/soc2009/http-wsgi-improvements/django/core/handlers/modpython.py
   django/branches/soc2009/http-wsgi-improvements/django/core/handlers/wsgi.py
   django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
   
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/sendfile/tests.py
Log:
[soc2009/http-wsgi-improvements] Establish the priorities and fallbacks for 
HttpResponseSendFile methods.

Change the setting to settings.HTTPRESPONSE_SENDFILE_METHOD. If this is set to 
None, we use handler methods,
but otherwise the header gets set, and we do not send any content. If neither 
of these are available,
use the FileWrapper fallback in HttpResponseSendFile.

This passes the test suite, but is untested on mod_python. I am still trying to 
figure out how to
view the headers of a response with the Content-Disposition "attachment."

Modified: 
django/branches/soc2009/http-wsgi-improvements/django/conf/global_settings.py
===
--- 
django/branches/soc2009/http-wsgi-improvements/django/conf/global_settings.py   
2009-07-17 20:04:03 UTC (rev 11267)
+++ 
django/branches/soc2009/http-wsgi-improvements/django/conf/global_settings.py   
2009-07-18 02:02:57 UTC (rev 11268)
@@ -236,9 +236,13 @@
 # Example: "http://media.lawrence.com;
 MEDIA_URL = ''
 
-# Header to use in HttpResponseSendFile to inform the handler to serve the 
-# file with efficient handler-specific routines. 
-HTTPRESPONSE_SENDFILE_HEADER = 'X-Sendfile' 
+# Header to use in HttpResponseSendFile to inform the handler to serve the
+# file with efficient handler-specific routines. None causes 
HttpResponseSendFile
+# to fall back to, first, mechanisms in the handler (wsgi.filewrapper and
+# req.sendfile.
+# Examples: 'X-Sendfile' (FastCGI, lighttpd, Apache with mod_xsendfile),
+#   'X-Accel-Redirect' (nginx)
+HTTPRESPONSE_SENDFILE_METHOD = None
 
 # List of upload handler classes to be applied in order.
 FILE_UPLOAD_HANDLERS = (

Modified: 
django/branches/soc2009/http-wsgi-improvements/django/core/handlers/modpython.py
===
--- 
django/branches/soc2009/http-wsgi-improvements/django/core/handlers/modpython.py
2009-07-17 20:04:03 UTC (rev 11267)
+++ 
django/branches/soc2009/http-wsgi-improvements/django/core/handlers/modpython.py
2009-07-18 02:02:57 UTC (rev 11268)
@@ -200,15 +200,15 @@
 for c in response.cookies.values():
 req.headers_out.add('Set-Cookie', c.output(header=''))
 req.status = response.status_code
-if isinstance(response, http.HttpResponseSendFile): 
-req.sendfile(response.sendfile_filename) 
+if isinstance(response, http.HttpResponseSendFile):
+req.sendfile(response.sendfile_filename)
 else:
-try:
-for chunk in response:
-req.write(chunk)
-finally:
-response.close()
-
+# If we are using a header to do sendfile, set the header and send 
empty content
+if settings.RESPONSE_SENDFILE_METHOD:
+response.set_empty_content()
+response[settings.HTTPRESPONSE_SENDFILE_METHOD] = 
response.sendfile_filename
+for chunk in response:
+req.write(chunk)
 return 0 # mod_python.apache.OK
 
 def handler(req):

Modified: 
django/branches/soc2009/http-wsgi-improvements/django/core/handlers/wsgi.py
===
--- django/branches/soc2009/http-wsgi-improvements/django/core/handlers/wsgi.py 
2009-07-17 20:04:03 UTC (rev 11267)
+++ django/branches/soc2009/http-wsgi-improvements/django/core/handlers/wsgi.py 
2009-07-18 02:02:57 UTC (rev 11268)
@@ -243,14 +243,11 @@
 start_response(status, response_headers)
 
 if isinstance(response, http.HttpResponseSendFile): 
-filelike = open(response.sendfile_filename, 'rb') 
-if 'wsgi.file_wrapper' in environ: 
+if settings.HTTPRESPONSE_SENDFILE_METHOD:
+response[settings.HTTPRESPONSE_SENDFILE_METHOD] = 
response.sendfile_filename
+elif 'wsgi.file_wrapper' in environ:
+filelike = open(response.sendfile_filename, 'rb')
 return environ['wsgi.file_wrapper'](filelike, 
-response.block_size) 
-else: 
-# wraps close() as well 
-from django.core.servers.basehttp import FileWrapper 
-return FileWrapper(filelike, response.block_size) 
-
+response.block_size)
 return response
 

Modified: 

Re: [Django] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:  1.2  
 Component:  HTTP handling   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by Glenn):

 (Sorry, I really don't want to learn a new source control system, and HG's
 webpage doesn't have a clear explanation of why, as a happy, expert
 Subversion user, I should even care about it.  They seem to expect me to
 learn how to use it, in order to figure out whether I should bother
 learning how to use it; it doesn't work that way...)

 "csrf_token" just seemed off to me--it's not a token that implements CSRF,
 it's a token that authorizes form submissions.

 I think "csrfmiddlewaretoken" in forms should be renamed to at least
 "csrftoken".  "Middleware" is an implementation detail--there's no need
 for that to leak into HTML.

-- 
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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:  1.2  
 Component:  HTTP handling   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Changes (by lukeplant):

  * milestone:  => 1.2

Comment:

 Thanks Glenn.

 I had already implemented some of this (in particular the
 CSRF_COOKIE_DOMAIN setting) in my hg repository that I mentioned before:
 http://bitbucket.org/spookylukey/django-trunk-lukeplant/

 I've now merged in your changes.  I kept the existing name of the CSRF
 cookie ("csrf_token") rather than use "authid" which seemed a bit obscure.
 If possible, 'hg bundles' or pull requests against that repo would be
 preferred -- I'm using a repos since this patch is rather long-lived and I
 want easy merges with trunk.

 At some point I'll implement the remaining things on the CsrfProtection
 page, but probably after it has been fully discussed, post the 1.1
 release.

 Note to other contributors: MOST RECENT PATCH IS NOT STORED ON THIS
 TICKET, but in hg repository mentioned above.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #9977: CSRFMiddleware needs template tag

[Django]

#9977: CSRFMiddleware needs template tag
-+--
  Reporter:  bthomas | Owner:  lukeplant
Status:  assigned| Milestone:   
 Component:  HTTP handling   |   Version:  SVN  
Resolution:  |  Keywords:  csrf 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Comment (by Glenn):

 Updated patch:

  - Remove _make_token and use the CSRF cookie directly as the token.
  - Don't uniquify the CSRF cookie based on the session cookie name.  This
 was needed when the CSRF token was hashed based on the site's secret key,
 but since it no longer is, it should be perfectly fine for all sites
 sharing cookies to share a CSRF token.
  - Added settings.CSRF_COOKIE_NAME and CSRF_COOKIE_DOMAIN for the CSRF
 cookie.
  - Updated docs and tests.  The previous two cookie settings,
 SESSION_COOKIE_NAME and LANGUAGE_COOKIE_NAME reference each other
 explicitly ("should be different from..."), but I didn't update that;
 having every cookie setting listing every other cookie setting doesn't
 seem like a good approach.  Maybe they should say "different from other
 COOKIE_NAME settings".
  - Tweaked the CSRF view error text; don't accuse hapless users of
 forgery.  (Of course, it's actually accusing some third party website of
 forgery, but most users wouldn't know that.)

 I didn't add a CSRF_COOKIE_PATH setting.  The rationale in the
 SESSION_COOKIE_PATH documentation (having separate sessions in different
 Django instances) doesn't apply here: it's perfectly OK for unrelated
 Django instances to pick up and reuse each other's authentication tokens
 if they're visible.  We can add it if someone actually wants it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone:  1.2
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by eppsilon):

 * cc: eppsilon (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
-~--~~~~--~~--~--~---

Re: [Django] #11433: Complete support for 3D Geometries

[Django]

#11433: Complete support for 3D Geometries
-+--
  Reporter:  jbronn  | Owner:  jbronn  
Status:  new | Milestone:  1.2 
 Component:  GIS |   Version:  SVN 
Resolution:  |  Keywords:  gis 3d z
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  1   |   Needs_tests:  1   
Needs_better_patch:  1   |  
-+--
Comment (by wibge):

 I applied the patch, and then ran into problems since I have some objects
 that are 2d and some 3d. I was getting "psycopg2.IntegrityError: new row
 for relation "site_trip" violates check constraint "enforce_dims_extent""
 when I tried to save 2d objects. I slightly changed the patch to check if
 it the geometry has a third dimension when it converts it to wkb.

-- 
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] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
--+-
  Reporter:  svsha...@intellecap.net  | Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by bendavis78):

 Regarding the example sql queries in comment 9
 [http://code.djangoproject.com/ticket/10060#comment:9 above],  I've
 discovered that the first query is actually faster.  My database has grown
 fairly large in the past few months, so I've been able to test with more
 clear results (this is using MySQL, by the way).

 Using the JOIN method (where the aggregates are done in a derived join),
 the query was extremely slow.  It took over 30 minutes to execute with
 57,000 rows in the users table.   When I changed the query to the SELECT
 method (where the aggregates are done in a subquery in the select clause),
 the query took only 2 seconds with the exact same results.  I spent a
 whole day on this, and couldn't find a solid explanation for why the
 derived join method was taking so long.  I'd say at this point if anyone
 moves forward with fixing this bug we should put the aggregate in the
 subquery of the select clause.

 I've looked around for an official stance on how to write a query with
 multiple aggregations across different joined tables,  and haven't come up
 with a solid answer.  If anyone does find "the right way" to do it, I'd be
 interested to know -- I think that definitely needs to be settled before
 this bug can 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] #11487: Oracle encoding bug when saving more than 4000 characters

[Django]

#11487: Oracle encoding bug when saving more than 4000 characters
---+
  Reporter:  mdpetry   | Owner:  nobody 

Status:  new   | Milestone:  1.1

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  oracle 
database
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Replying to [comment:8 dg]:
 > I belive it should say "as _a_ CLOB" (just a grammar nitpick ;))

 I just attached a patch with the correct grammar.

-- 
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] r11267 - django/trunk/django/conf/locale/pl/LC_MESSAGES

[noreply]

Author: zgoda
Date: 2009-07-17 15:04:03 -0500 (Fri, 17 Jul 2009)
New Revision: 11267

Modified:
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
Log:
Fixed #11498 - fix wrong translation in admin actions form. Thanks for sayane 
for report and patch.


Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-07-17 
20:00:13 UTC (rev 11266)
+++ django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-07-17 
20:04:03 UTC (rev 11267)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-05-20 12:58+0200\n"
+"POT-Creation-Date: 2009-07-17 21:59+0200\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -223,7 +223,7 @@
 msgid "Successfully deleted %(count)d %(items)s."
 msgstr "Usunięto %(count)d %(items)s."
 
-#: contrib/admin/actions.py:67 contrib/admin/options.py:1025
+#: contrib/admin/actions.py:67 contrib/admin/options.py:1027
 msgid "Are you sure?"
 msgstr "Jesteś pewien?"
 
@@ -321,7 +321,7 @@
 
 #: contrib/admin/options.py:519 contrib/admin/options.py:529
 #: contrib/comments/templates/comments/preview.html:16 forms/models.py:388
-#: forms/models.py:587
+#: forms/models.py:600
 msgid "and"
 msgstr "i"
 
@@ -344,53 +344,53 @@
 msgid "No fields changed."
 msgstr "Żadne pole nie zmienione."
 
-#: contrib/admin/options.py:598 contrib/auth/admin.py:67
+#: contrib/admin/options.py:599 contrib/auth/admin.py:67
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was added successfully."
 msgstr "%(name)s \"%(obj)s\" dodany pomyślnie."
 
-#: contrib/admin/options.py:602 contrib/admin/options.py:635
+#: contrib/admin/options.py:603 contrib/admin/options.py:636
 #: contrib/auth/admin.py:75
 msgid "You may edit it again below."
 msgstr "Możesz ponownie edytować wpis poniżej."
 
-#: contrib/admin/options.py:612 contrib/admin/options.py:645
+#: contrib/admin/options.py:613 contrib/admin/options.py:646
 #, python-format
 msgid "You may add another %s below."
 msgstr "Możesz dodać nowy wpis %s poniżej."
 
-#: contrib/admin/options.py:633
+#: contrib/admin/options.py:634
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was changed successfully."
 msgstr "%(name)s \"%(obj)s\" zostało pomyślnie zmienione."
 
-#: contrib/admin/options.py:641
+#: contrib/admin/options.py:642
 #, python-format
 msgid ""
 "The %(name)s \"%(obj)s\" was added successfully. You may edit it again below."
 msgstr ""
 "%(name)s \"%(obj)s\" dodane pomyślnie. Możesz edytować ponownie wpis poniżej."
 
-#: contrib/admin/options.py:772
+#: contrib/admin/options.py:773
 #, python-format
 msgid "Add %s"
 msgstr "Dodaj %s"
 
-#: contrib/admin/options.py:803 contrib/admin/options.py:1003
+#: contrib/admin/options.py:804 contrib/admin/options.py:1005
 #, python-format
 msgid "%(name)s object with primary key %(key)r does not exist."
 msgstr "Obiekt %(name)s o kluczu głównym %(key)r nie istnieje."
 
-#: contrib/admin/options.py:860
+#: contrib/admin/options.py:861
 #, python-format
 msgid "Change %s"
 msgstr "Zmień %s"
 
-#: contrib/admin/options.py:904
+#: contrib/admin/options.py:905
 msgid "Database error"
 msgstr "Błąd bazy danych"
 
-#: contrib/admin/options.py:940
+#: contrib/admin/options.py:941
 #, python-format
 msgid "%(count)s %(name)s was changed successfully."
 msgid_plural "%(count)s %(name)s were changed successfully."
@@ -398,17 +398,17 @@
 msgstr[1] "%(count)s %(name)s zostały pomyślnie zmienione."
 msgstr[2] "%(count)s %(name)s zostało pomyślnie zmienionych."
 
-#: contrib/admin/options.py:1018
+#: contrib/admin/options.py:1020
 #, python-format
 msgid "The %(name)s \"%(obj)s\" was deleted successfully."
 msgstr "%(name)s \"%(obj)s\" usunięty pomyślnie."
 
-#: contrib/admin/options.py:1054
+#: contrib/admin/options.py:1057
 #, python-format
 msgid "Change history: %s"
 msgstr "Historia zmian: %s"
 
-#: contrib/admin/sites.py:20 contrib/admin/views/decorators.py:14
+#: contrib/admin/sites.py:21 contrib/admin/views/decorators.py:14
 #: contrib/auth/forms.py:80
 msgid ""
 "Please enter a correct username and password. Note that both fields are case-"
@@ -417,11 +417,11 @@
 "Proszę wpisać poprawną nazwę użytkownika i hasło. Uwaga: wielkość liter ma "
 "znaczenie."
 
-#: contrib/admin/sites.py:278 contrib/admin/views/decorators.py:40
+#: contrib/admin/sites.py:285 contrib/admin/views/decorators.py:40
 msgid "Please log in again, because your session has expired."
 msgstr "Twoja sesja wygasła, zaloguj się ponownie."
 
-#: contrib/admin/sites.py:285 contrib/admin/views/decorators.py:47
+#: contrib/admin/sites.py:292 

Re: [Django] #11498: Little mistake in Polish translation

[Django]

#11498: Little mistake in Polish translation
---+
  Reporter:  sayane| Owner:  zgoda 
Status:  assigned  | Milestone:  1.1   
 Component:  Translations  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by zgoda):

  * owner:  nobody => zgoda
  * 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
-~--~~~~--~~--~--~---

[Changeset] r11266 - in django/branches/soc2009/http-wsgi-improvements: django/http tests/regressiontests/charsets

[noreply]

Author: ccahoon
Date: 2009-07-17 15:00:13 -0500 (Fri, 17 Jul 2009)
New Revision: 11266

Modified:
   django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
   
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/tests.py
   
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/urls.py
   
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/views.py
Log:
[soc2009/http-wsgi-improvements] Throw an exception when HttpResponse.codec is 
set with a bad value. Improved coverage of encoding changes in request and 
response headers. Refs #10190.

Passes the test suite.

Modified: django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
===
--- django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 16:44:57 UTC (rev 11265)
+++ django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 20:00:13 UTC (rev 11266)
@@ -373,8 +373,11 @@
 return self._codec
 
 def _set_codec(self, value):
-if hasattr(value, "name"):
-self._codec = value
+if not hasattr(value, "name"):
+# This is slightly more permissive, allowing any object with the
+# "name" attribute.
+raise Exception("Codec should be provided with a CodecInfo 
object.")
+self._codec = value
 
 codec = property(_get_codec, _set_codec)
 

Modified: 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/tests.py
===
--- 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/tests.py
  2009-07-17 16:44:57 UTC (rev 11265)
+++ 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/tests.py
  2009-07-17 20:00:13 UTC (rev 11266)
@@ -16,12 +16,20 @@
 
 class ClientTest(TestCase):
 urls = 'regressiontests.charsets.urls'
-
+test_string = u'\u82cf\u8054\u961f'
+codec = get_codec("GBK")
+
+def encode(self, string):
+return self.codec.encode(string)[0]
+
+def decode(self, string):
+return self.codec.decode(string)[0]
+
 def test_good_accept_charset(self):
 "Use Accept-Charset, with a quality value that throws away 
default_charset"
 # The data is ignored, but let's check it doesn't crash the system
 # anyway.
-
+
 response = self.client.post('/accept_charset/', 
ACCEPT_CHARSET="ascii,utf-8;q=0")
 
 self.assertEqual(response.status_code, 200)
@@ -91,3 +99,27 @@
 self.assertEqual(response.status_code, 200)
 self.assertEqual(get_charset(response), settings.DEFAULT_CHARSET)
 
+def test_encode_content_type(self):
+"Make sure a request gets encoded according to the content type in the 
view."
+response = self.client.post('/encode_response_content_type/')
+self.assertEqual(response.status_code, 200)
+self.assertEqual(get_codec(get_charset(response)).name, 
self.codec.name)
+self.assertEqual(response.content, self.encode(self.test_string))
+
+def test_encode_accept_charset(self):
+"Make sure a request gets encoded according to the Accept-Charset 
request header."
+response = self.client.post('/encode_response_accept_charset/',
+ ACCEPT_CHARSET="gbk;q=1,utf-8;q=0.9")
+
+self.assertEqual(response.status_code, 200)
+self.assertEqual(get_codec(get_charset(response)).name, 
self.codec.name)
+self.assertEqual(response.content, self.encode(self.test_string))
+
+def test_bad_codec(self):
+"Assure we get an Exception for setting a bad codec in the view."
+self.assertRaises(Exception, self.client.post, '/bad_codec/')
+
+def test_good_codecs(self):
+response = self.client.post('/good_codec/')
+self.assertEqual(response.status_code, 200)
+self.assertEqual(response.content, self.encode(self.test_string))

Modified: 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/urls.py
===
--- 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/urls.py
   2009-07-17 16:44:57 UTC (rev 11265)
+++ 
django/branches/soc2009/http-wsgi-improvements/tests/regressiontests/charsets/urls.py
   2009-07-17 20:00:13 UTC (rev 11266)
@@ -20,4 +20,8 @@
 (r'^bad_content_type/', views.bad_content_type),
 (r'^content_type_no_charset/', views.content_type_no_charset),
 (r'^basic_response/', views.basic_response),
+(r'^good_codec/', views.good_codec),
+(r'^bad_codec/', views.bad_codec),
+(r'^encode_response_content_type/', views.encode_response_content_type),
+(r'^encode_response_accept_charset/', 
views.encode_response_accept_charset),
 )

Re: [Django] #11498: Little mistake in Polish translation

[Django]

#11498: Little mistake in Polish translation
---+
  Reporter:  sayane| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Translations  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by sayane):

  * needs_better_patch:  => 0
  * version:  1.0 => 1.1-beta-1
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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
-~--~~~~--~~--~--~---

[Django] #11498: Little mistake in Polish translation

[Django]

#11498: Little mistake in Polish translation
--+-
 Reporter:  sayane|   Owner:  nobody
   Status:  new   |   Milestone:  1.1   
Component:  Translations  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 There is a little mistake in Polish translation in admin actions. In
 context of admin actions "Go" should be translated as "Wykonaj" or
 something similar. Actual value - "Szukaj" means "Search".

-- 
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] r11265 - in django/trunk: . docs/internals

[noreply]

Author: jbronn
Date: 2009-07-17 11:44:57 -0500 (Fri, 17 Jul 2009)
New Revision: 11265

Modified:
   django/trunk/AUTHORS
   django/trunk/docs/internals/committers.txt
Log:
Added myself to AUTHORS and updated my bio.


Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2009-07-17 15:57:43 UTC (rev 11264)
+++ django/trunk/AUTHORS2009-07-17 16:44:57 UTC (rev 11265)
@@ -14,6 +14,7 @@
 * Robert Wittams
 * Gary Wilson
 * Brian Rosner
+* Justin Bronn
 * Karen Tracey
 
 More information on the main contributors to Django can be found in

Modified: django/trunk/docs/internals/committers.txt
===
--- django/trunk/docs/internals/committers.txt  2009-07-17 15:57:43 UTC (rev 
11264)
+++ django/trunk/docs/internals/committers.txt  2009-07-17 16:44:57 UTC (rev 
11265)
@@ -154,6 +154,19 @@
 broken windows. He's continued to do that necessary tidying up work
 throughout the code base since then.
 
+Justin Bronn
+Justin Bronn is a computer scientist and attorney specializing
+in legal topics related to intellectual property and spatial law.
+
+In 2007, Justin began developing ``django.contrib.gis`` in a branch,
+a.k.a. GeoDjango_, which was merged in time for Django 1.0.  While
+implementing GeoDjango, Justin obtained a deep knowledge of Django's
+internals including the ORM, the admin, and Oracle support.
+
+Justin lives in Houston, Texas.
+
+.. _GeoDjango: http://geodjango.org/
+
 Karen Tracey
 Karen has a background in distributed operating systems (graduate school),
 communications software (industry) and crossword puzzle construction
@@ -187,16 +200,6 @@
 Matt Boersma
 Matt is also responsible for Django's Oracle support.
 
-Justin Bronn
-Justin Bronn is a computer scientist and third-year law student at the
-University of Houston who enjoys studying legal topics related to
-intellectual property and spatial law.
-
-Justin is the primary developer of ``django.contrib.gis``, a.k.a.
-GeoDjango_.
-
-.. _GeoDjango: http://geodjango.org/
-
 Jeremy Dunck
 Jeremy the lead developer of Pegasus News, a personalized local site based
 in Dallas, Texas. An early contributor to Greasemonkey and Django, he sees


--~--~-~--~~~---~--~~
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] #8336: runserver option for disabling admin static files serving

[Django]

#8336: runserver option for disabling admin static files serving
+---
  Reporter:  jakub_vysoky   | Owner:  nobody
   
Status:  closed | Milestone:
   
 Component:  django-admin.py runserver  |   Version:  SVN   
   
Resolution:  wontfix|  Keywords:  admin media 
runserver
 Stage:  Design decision needed | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 Please don't reopen tickets closed by a commiter, if you disagree with the
 decision take it to the django-developers mailing list.

-- 
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] r11264 - in django/branches/soc2009/multidb: django/db/models django/db/models/fields django/db/models/sql django/forms docs/howto tests/regressiontests/model_fields

[noreply]

Author: Alex
Date: 2009-07-17 10:57:43 -0500 (Fri, 17 Jul 2009)
New Revision: 11264

Modified:
   django/branches/soc2009/multidb/django/db/models/base.py
   django/branches/soc2009/multidb/django/db/models/fields/__init__.py
   django/branches/soc2009/multidb/django/db/models/fields/files.py
   django/branches/soc2009/multidb/django/db/models/fields/related.py
   django/branches/soc2009/multidb/django/db/models/related.py
   django/branches/soc2009/multidb/django/db/models/sql/subqueries.py
   django/branches/soc2009/multidb/django/db/models/sql/where.py
   django/branches/soc2009/multidb/django/forms/models.py
   django/branches/soc2009/multidb/docs/howto/custom-model-fields.txt
   django/branches/soc2009/multidb/tests/regressiontests/model_fields/tests.py
Log:
[soc2009/multidb] Added connection parameter to the get_db_prep_* family of 
functions.  This allows us to generate the lookup and save values for Fields in 
a backend specific manner.

Modified: django/branches/soc2009/multidb/django/db/models/base.py
===
--- django/branches/soc2009/multidb/django/db/models/base.py2009-07-17 
12:36:29 UTC (rev 11263)
+++ django/branches/soc2009/multidb/django/db/models/base.py2009-07-17 
15:57:43 UTC (rev 11264)
@@ -18,6 +18,7 @@
 from django.db import connections, transaction, DatabaseError, DEFAULT_DB_ALIAS
 from django.db.models import signals
 from django.db.models.loading import register_models, get_model
+from django.db.utils import call_with_connection
 from django.utils.functional import curry
 from django.utils.encoding import smart_str, force_unicode, smart_unicode
 from django.conf import settings
@@ -483,9 +484,11 @@
 if not pk_set:
 if force_update:
 raise ValueError("Cannot force an update in save() 
with no primary key.")
-values = [(f, f.get_db_prep_save(raw and getattr(self, 
f.attname) or f.pre_save(self, True))) for f in meta.local_fields if not 
isinstance(f, AutoField)]
+values = [(f, call_with_connection(f.get_db_prep_save, raw 
and getattr(self, f.attname) or f.pre_save(self, True), connection=connection))
+for f in meta.local_fields if not isinstance(f, 
AutoField)]
 else:
-values = [(f, f.get_db_prep_save(raw and getattr(self, 
f.attname) or f.pre_save(self, True))) for f in meta.local_fields]
+values = [(f, call_with_connection(f.get_db_prep_save, raw 
and getattr(self, f.attname) or f.pre_save(self, True), connection=connection))
+for f in meta.local_fields]
 
 if meta.order_with_respect_to:
 field = meta.order_with_respect_to

Modified: django/branches/soc2009/multidb/django/db/models/fields/__init__.py
===
--- django/branches/soc2009/multidb/django/db/models/fields/__init__.py 
2009-07-17 12:36:29 UTC (rev 11263)
+++ django/branches/soc2009/multidb/django/db/models/fields/__init__.py 
2009-07-17 15:57:43 UTC (rev 11264)
@@ -11,6 +11,7 @@
 from django.db import connection
 from django.db.models import signals
 from django.db.models.query_utils import QueryWrapper
+from django.db.utils import call_with_connection
 from django.dispatch import dispatcher
 from django.conf import settings
 from django import forms
@@ -178,7 +179,7 @@
 "Returns field's value just before saving."
 return getattr(model_instance, self.attname)
 
-def get_db_prep_value(self, value):
+def get_db_prep_value(self, value, connection):
 """Returns field's value prepared for interacting with the database
 backend.
 
@@ -187,11 +188,12 @@
 """
 return value
 
-def get_db_prep_save(self, value):
+def get_db_prep_save(self, value, connection):
 "Returns field's value prepared for saving into a database."
-return self.get_db_prep_value(value)
+return call_with_connection(self.get_db_prep_value, value,
+connection=connection)
 
-def get_db_prep_lookup(self, lookup_type, value):
+def get_db_prep_lookup(self, lookup_type, value, connection):
 "Returns field's value prepared for database lookup."
 if hasattr(value, 'as_sql') or hasattr(value, '_as_sql'):
 # If the value has a relabel_aliases method, it will need to
@@ -208,9 +210,9 @@
 if lookup_type in ('regex', 'iregex', 'month', 'day', 'week_day', 
'search'):
 return [value]
 elif lookup_type in ('exact', 'gt', 'gte', 'lt', 'lte'):
-return [self.get_db_prep_value(value)]
+return [call_with_connection(self.get_db_prep_value, value, 
connection=connection)]
 elif lookup_type in ('range', 'in'):
-return [self.get_db_prep_value(v) for v in value]
+return 

Re: [Django] #8336: runserver option for disabling admin static files serving

[Django]

#8336: runserver option for disabling admin static files serving
+---
  Reporter:  jakub_vysoky   | Owner:  nobody
   
Status:  reopened   | Milestone:
   
 Component:  django-admin.py runserver  |   Version:  SVN   
   
Resolution: |  Keywords:  admin media 
runserver
 Stage:  Design decision needed | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

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

Comment:

 Burned several hours scratching my head with this on multiple occasions as
 well. In DEBUG mode I have my media/ served with the django static serve
 in urls.py, and admin/ is a subfolder of that. However this django
 'feature' overrides my media/admin/ with the django builtins.

 Re-opening since this 'feature' is affecting a lot of people. This silent
 magic overriding of media directories is a really bad idea, and none of
 the proposed workarounds are useful. Having to type --adminmedia each time
 is a really horrible idea; if I work on something else for a week, then
 come back to it, I always forget, and burn yet another hour wondering why
 my customizations aren't showing up.

 At the VERY least, my urls.py should override django's magic, not the
 other way around. If I'm specifying a media/ folder, obviously I will need
 admin/ in it on production, so django should assume I will have it set up
 the same way in 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
-~--~~~~--~~--~--~---

Re: [Django] #6064: Allow database connection initialization commands

[Django]

#6064: Allow database connection initialization commands
---+
  Reporter:  jacob | Owner:  floguy
Status:  closed| Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by euphoria):

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

Comment:

 Please ask questions like this on an appropriate mailing list (django-user
 in this case) instead of resurrecting old tickets.

 {{{
 def set_schema(sender, **kwargs):
 from django.db import connection

 cursor = connection.cursor()
 cursor.execute("INITIALIZE SOME THINGS VIA SQL")

 if django.VERSION >= (1,1):
 from django.db.backends.signals import connection_created
 connection_created.connect(set_schema)
 }}}

-- 
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] #11497: Overwriting base_site.html in admin site removes some js components

[Django]

#11497: Overwriting base_site.html in admin site removes some js components
---+
  Reporter:  szczav| Owner:  nobody 
   
Status:  new   | Milestone:  1.1
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  base_site.html 
java script js template
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Can you provide some more details (particularly the source of your file),
 as it stands we have no idea where the possible regression could be.

-- 
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
-~--~~~~--~~--~--~---

[Django] #11497: Overwriting base_site.html in admin site removes some js components

[Django]

#11497: Overwriting base_site.html in admin site removes some js components
+---
 Reporter:  szczav  |   Owner:  nobody
   Status:  new |   Milestone:  1.1   
Component:  django.contrib.admin| Version:  SVN   
 Keywords:  base_site.html java script js template  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 In admin templates I've my own base_site.html template in which I changed
 only title. In stable release it was working correctly. In SVN version I
 see that some java script components (for example calendar, time and some
 for many to many fields) don't appear. When I remove base_site template
 everything works correctly.

-- 
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] #11478: jsi18n loading from templates within django/contrib/admin/templates/ shouldn't use "../"s

[Django]

#11478: jsi18n loading from templates within django/contrib/admin/templates/
shouldn't use "../"s
---+
  Reporter:  greatlemer   | Owner: 
 nobody
Status:  new   | Milestone: 
   
 Component:  django.contrib.admin  |   Version: 
 SVN   
Resolution:|  Keywords: 
   
 Stage:  Unreviewed| Has_patch: 
 1 
Needs_docs:  0 |   Needs_tests: 
 0 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 With #10061 fixed on r11250, now the patch should work when applied to
 trunk after hat revision. Please report back your experiences with it if
 you manage to give it a try.

-- 
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
+---
  Reporter:  bhagany| Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by bhagany):

 @ccahoon Sounds great!  I've been following the work in your branch, and
 I'm happy to have saved you a teensy bit of work.

 Also, re: accepted status - noted, and thanks for explaining.

-- 
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 Barr   | Owner: 
 ccahoon  
Status:  new   | Milestone: 
  
 Component:  HTTP handling |   Version: 
 SVN  
Resolution:|  Keywords: 
 Content-Length middleware
 Stage:  Design decision needed| Has_patch: 
 1
Needs_docs:  0 |   Needs_tests: 
 0
Needs_better_patch:  0 |  
---+
Changes (by ccahoon):

  * owner:  nobody => ccahoon

-- 
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] #5076: Request object should try to determine encoding

[Django]

#5076: Request object should try to determine encoding
+---
  Reporter:  dbr   | Owner:  ccahoon   
 
Status:  new| Milestone:
 
 Component:  HTTP handling  |   Version:  SVN   
 
Resolution: |  Keywords:  unicode 
conversion charset POST request
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Changes (by ccahoon):

  * owner:  nobody => ccahoon

-- 
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] #6064: Allow database connection initialization commands

[Django]

#6064: Allow database connection initialization commands
---+
  Reporter:  jacob | Owner:  floguy
Status:  reopened  | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by hank@gmail.com):

 * cc: hank@gmail.com (added)
  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 I am reopening this ticket because the accepted patch does not appear to
 address the same issue as the original patch. The original patch performed
 initialization work on each connection as it was established. The accepted
 patch fires a signal when a connection has been created, but the sender is
 the class, not the newly created connection, so how can the desired
 initialization be performed? If there is a consensus that the sender
 should be changed to the new connection, I am happy to submit a patch that
 does that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #9081: [patch] More flexible render_to_response()

[Django]

#9081: [patch] More flexible render_to_response()
+---
  Reporter:  bhagany| Owner:  ccahoon
Status:  new| Milestone: 
 Component:  HTTP handling  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by ccahoon):

 * cc: chris.cah...@gmail.com (added)
  * owner:  nobody => ccahoon

-- 
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  | Milestone:  
  
 Component:  HTTP handling|   Version:  SVN 
  
Resolution:   |  Keywords:  http 
iterators
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by ccahoon):

 @stugots Hopefully we can get this patch into trunk at the end of SoC2009.
 I changed the ownership so I don't forget to address it when I am
 reviewing my changes later on.

-- 
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  | Milestone:  
  
 Component:  HTTP handling|   Version:  SVN 
  
Resolution:   |  Keywords:  http 
iterators
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by ccahoon):

  * owner:  stugots => ccahoon
  * status:  assigned => new

-- 
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
+---
  Reporter:  bhagany| Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ccahoon):

 @bhagany Actually, I will probably spend some time hopping between the two
 patches you've submitted and get advice from my mentor. They both look
 good, but the other is indeed very flexible, and I don't see any problems
 with it yet.

-- 
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] r11263 - django/branches/soc2009/http-wsgi-improvements/django/http

[noreply]

Author: ccahoon
Date: 2009-07-17 07:36:29 -0500 (Fri, 17 Jul 2009)
New Revision: 11263

Modified:
   django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
Log:
[soc2009/http-wsgi-improvements] Add docs that I missed from the patch and 
reformat HttpResponse.__str__. refs #6527

This and the previous revision on this branch appear to complete all the 
changes from #6527.

Modified: django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
===
--- django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 11:48:08 UTC (rev 11262)
+++ django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 12:36:29 UTC (rev 11263)
@@ -288,6 +288,7 @@
 if not content_type:
 content_type = "%s; charset=%s" % (settings.DEFAULT_CONTENT_TYPE,
 self._charset)
+# Expects content to be an iterable container or a string.
 self._container = [''.join(content)]
 if hasattr(content, 'close'):
 content.close()
@@ -301,8 +302,8 @@
 
 def __str__(self):
 """Full HTTP message, including headers."""
-headers = ['%s: %s' % (k, v) for k, v in self._headers.values()]
-return '\n'.join(headers) + '\n\n' + self.content
+return '\n'.join(['%s: %s' % (k, v) for k, v in 
self._headers.values()]) \
+   + "\n\n" + self.content
 
 def _convert_to_ascii(self, *values):
 """Converts all values to ascii strings."""
@@ -414,7 +415,7 @@
 return str(chunk)
 
 def close(self):
-"No-op that remains for backwards compatibility. Ref #6527"
+"No-op. Remains for backwards compatibility. Refs #6527"
 pass
 
 # The remaining methods partially implement the file-like object interface.


--~--~-~--~~~---~--~~
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
+---
  Reporter:  bhagany| Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ccahoon):

  * needs_tests:  1 => 0

Comment:

 @bhagany As I understand it, "Accepted" means that he thinks the general
 idea of the ticket is valid, not that the patch is accepted. If the patch
 was accepted, jacob would have committed the changes. I think it's a fine
 patch, though. I found this ticket looking to see if someone had already
 done the work I was about to on my GSoC branch, and there yours is. I am
 going to apply your changes to my SoC branch, so it will be bound to get
 reviewed within a month or so.

-- 
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] #10808: Multiple inheritance (model-based) broken for __init__ of common fields in diamond inheritance

[Django]

#10808: Multiple inheritance (model-based) broken for __init__ of common fields 
in
diamond inheritance
---+
  Reporter:  mikemintz | Owner:  jianhuang
Status:  assigned  | Milestone:   
 Component:  Database layer (models, ORM)  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by lsaffre):

 Patch 10808.diff fixes only one symptom, not the real problem.
 The real problem is that in case of diamond inheritance there are
 duplicate field definitions.
 My patch 10808b.diff won't fix the real problem, but another symptom: when
 the top-level model of your diamond structure contains a ForeignKey, then
 you get problems when trying to create inline formsets. To show this
 problem I added a "Owner" class to SmileyChris's diamond inheritance test.
 inlineformset_factory() gets disturbed because it thinks that PizzeriaBar
 contains more than one foreign key to Owner. The workaround is to specify
 the fk_name explicitly when calling inlineformset_factory(). Unfortunately
 this workaround needs another patch because inlineformset_factory() just
 can't imagine that a model can have two fields with the same name.
 Patch 10808b.diff contains 10808.diff + my suggestion.

-- 
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] r11261 - django/branches/soc2009/http-wsgi-improvements/django/http

[noreply]

Author: ccahoon
Date: 2009-07-17 06:47:54 -0500 (Fri, 17 Jul 2009)
New Revision: 11261

Modified:
   django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
Log:
[soc2009/http-wsgi-improvements] Fix HttpResponseSendFile indentation issue and 
set its initial content to be an empty string, for compatibility with ticket 
refs #6527.

Modified: django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py
===
--- django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 11:33:35 UTC (rev 11260)
+++ django/branches/soc2009/http-wsgi-improvements/django/http/__init__.py  
2009-07-17 11:47:54 UTC (rev 11261)
@@ -442,19 +442,18 @@
 sendfile_fh = None
 
 def __init__(self, path_to_file, content_type=None, block_size=8192): 
-   if not content_type: 
-   from mimetypes import guess_type 
-   content_type = guess_type(path_to_file)[0] 
-   if content_type is None: 
-   content_type = "application/octet-stream" 
-   super(HttpResponseSendFile, self).__init__(None, 
-   content_type=content_type) 
-   self.sendfile_filename = path_to_file 
-   self.block_size = block_size 
-   self['Content-Length'] = os.path.getsize(path_to_file) 
-   self['Content-Disposition'] = ('attachment; filename=%s' % 
-   os.path.basename(path_to_file)) 
-   self[settings.HTTPRESPONSE_SENDFILE_HEADER] = path_to_file 
+if not content_type:
+from mimetypes import guess_type
+content_type = guess_type(path_to_file)[0]
+if content_type is None:
+content_type = "application/octet-stream"
+super(HttpResponseSendFile, self).__init__('', 
content_type=content_type)
+self.sendfile_filename = path_to_file
+self.block_size = block_size
+self['Content-Length'] = os.path.getsize(path_to_file)
+self['Content-Disposition'] = ('attachment; filename=%s' %
+ os.path.basename(path_to_file))
+self[settings.HTTPRESPONSE_SENDFILE_HEADER] = path_to_file
 
 def __iter__(self):
 from django.core.servers.basehttp import FileWrapper


--~--~-~--~~~---~--~~
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] #10427: Bound field needs an easy way to get form value

[Django]

#10427: Bound field needs an easy way to get form value
---+
  Reporter:  toxik | Owner:  nobody  
Status:  reopened  | Milestone:  
 Component:  Forms |   Version:  SVN 
Resolution:|  Keywords:  form field value
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by Michael Stevens ):

 This would be very handy for me having spent hours trying and failing to
 do related things.

-- 
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] #11496: max_value validation is inconsistant

[Django]

#11496: max_value validation is inconsistant
-+--
  Reporter:  bobbo...@gmail.com  | Owner:  nobody   
Status:  new | Milestone:  1.0.3
 Component:  Forms   |   Version:  1.0  
Resolution:  |  Keywords:  max_value
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by ubernostrum):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> I am attempting to use validation in the following modelform:
>
> class BatchForm(ModelForm):
> amount =
> forms.DecimalField(max_digits=8,decimal_places=2,max_value=59.99)
> class Meta:
> model = Batch
> exclude = ('submit_date','user')
>
> Sometimes is_valid() returns true and sometimes it returns false with the
> amount 1212.
>
> The error returnedis:
>
> Ensure this value is less than or equal to 59.99.
>
> Is this a know issue?
>
> Version Django-1.0.2-final Python 2.5.1 Mac OSX 10.5.7

New description:

 I am attempting to use validation in the following modelform:

 {{{
 class BatchForm(ModelForm):
 amount =
 forms.DecimalField(max_digits=8,decimal_places=2,max_value=59.99)
 class Meta:
 model = Batch
 exclude = ('submit_date','user')
 }}}

 Sometimes is_valid() returns true and sometimes it returns false with the
 amount 1212.

 The error returnedis:

 Ensure this value is less than or equal to 59.99.

 Is this a know issue?

 Version Django-1.0.2-final Python 2.5.1 Mac OSX 10.5.7

Comment:

 (formatting)

-- 
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
-~--~~~~--~~--~--~---