date:20081023

Re: [Django] #8116: django.template.loader.select_template should not silently skip a template which includes another template that does not exist

2008-10-23 Thread Django

#8116: django.template.loader.select_template should not silently skip a 
template
which includes another template that does not exist
-+--
  Reporter:  Michael P. Jung | Owner:  nobody  
Status:  new | Milestone:  post-1.0
 Component:  Template system |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by Mike Amy):

 Ran into this one...

 Problem is bad exception handling... TemplateDoesNotExist exceptions
 arising from the missing child templates are ignored in select_template,
 in effect causing it to ignore the parent template. A fix is to check the
 message in the exception (in django/template/loader.py ):
 {{{
 def select_template(template_name_list):
 "Given a list of template names, returns the first that can be
 loaded."
 for template_name in template_name_list:
 try:
 return get_template(template_name)
 except TemplateDoesNotExist, e:
 if e.message is template_name: # <<< Check the template is not
 a child template
 continue
 raise
 # If we get here, none of the templates could be loaded
 raise TemplateDoesNotExist, template_name_list
 }}}

 However, that is making assumptions about the exception, there ought to be
 a better way, like a template_name attribute in the exception

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2201: TypeError: Cannot resolve keyword ___ into field

2008-10-23 Thread Django

#2201: TypeError: Cannot resolve keyword ___ into field
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  adrian
Status:  closed| Milestone:
 Component:  Core framework|   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by alsleme):

 [http://www.travelerpedia.net/ فنادق]
 [http://www.travelerpedia.net/africa/egypt/cairo/ القاهرة]
 [http://www.travelerpedia.net/photo/ صور فنادق]
 [http://www.travelerpedia.net/africa/egypt/sharm_el_sheikh/ فنادق شرم
 الشيخ]
 [http://www.travelerpedia.net/africa/egypt/alexandria/ الاسكندرية]
 [http://www.travelerpedia.net/africa/egypt/alexandria/ مصر]
 [http://www.travelerpedia.net/africa/egypt/alexandria/ فنادق الاسكندرية]
 [http://www.travelerpedia.net/asia/uae/dubai/ دبي]
 [http://www.travelerpedia.net/asia/uae/dubai/ فنادق دبي]
 [http://www.travelerpedia.net/asia/uae/ فنادق الامارات]
 [http://www.travelerpedia.net/asia/malaysia/kuala-lumpur/ فنادق
 كوالالمبور]
 [http://www.travelerpedia.net/asia/malaysia/penang/ فنادق بينانج]
 [http://www.travelerpedia.net/asia/malaysia/ فنادق ماليزيا]
 [http://www.travelerpedia.net/asia/malaysia/langkawi/ فنادق لنكاوي]
 [http://www.travelerpedia.net/asia/turkey/istanbul/ فنادق اسطنبول]
 [http://www.travelerpedia.net/asia/turkey/ فنادق تركيا]

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9250 - in django/branches/releases/1.0.X: . django/core tests/regressiontests/mail

2008-10-23 Thread noreply


Author: mtredinnick
Date: 2008-10-23 23:41:58 -0500 (Thu, 23 Oct 2008)
New Revision: 9250

Modified:
   django/branches/releases/1.0.X/AUTHORS
   django/branches/releases/1.0.X/django/core/mail.py
   django/branches/releases/1.0.X/tests/regressiontests/mail/tests.py
Log:
[1.0.X] Fixed #9383 -- Don't open a network connection for sending email if
there's nothing to send. Saves a bit of time when, for example, processing
500-error emails with no ADMINs configured. Based on a patch from Jesse Young.

Backport of r9248 from trunk.


Modified: django/branches/releases/1.0.X/AUTHORS
===
--- django/branches/releases/1.0.X/AUTHORS  2008-10-24 04:40:51 UTC (rev 
9249)
+++ django/branches/releases/1.0.X/AUTHORS  2008-10-24 04:41:58 UTC (rev 
9250)
@@ -422,6 +422,7 @@
 Jason Yan <[EMAIL PROTECTED]>
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
+Jesse Young <[EMAIL PROTECTED]>
 Jarek Zgoda <[EMAIL PROTECTED]>
 Cheng Zhang
 

Modified: django/branches/releases/1.0.X/django/core/mail.py
===
--- django/branches/releases/1.0.X/django/core/mail.py  2008-10-24 04:40:51 UTC 
(rev 9249)
+++ django/branches/releases/1.0.X/django/core/mail.py  2008-10-24 04:41:58 UTC 
(rev 9250)
@@ -268,6 +268,10 @@
 
 def send(self, fail_silently=False):
 """Sends the email message."""
+if not self.recipients():
+# Don't bother creating the network connection if there's nobody to
+# send to.
+return 0
 return self.get_connection(fail_silently).send_messages([self])
 
 def attach(self, filename=None, content=None, mimetype=None):
@@ -366,12 +370,16 @@
 
 def mail_admins(subject, message, fail_silently=False):
 """Sends a message to the admins, as defined by the ADMINS setting."""
+if not settings.ADMINS:
+return
 EmailMessage(settings.EMAIL_SUBJECT_PREFIX + subject, message,
  settings.SERVER_EMAIL, [a[1] for a in settings.ADMINS]
  ).send(fail_silently=fail_silently)
 
 def mail_managers(subject, message, fail_silently=False):
 """Sends a message to the managers, as defined by the MANAGERS setting."""
+if not settings.MANAGERS:
+return
 EmailMessage(settings.EMAIL_SUBJECT_PREFIX + subject, message,
  settings.SERVER_EMAIL, [a[1] for a in settings.MANAGERS]
  ).send(fail_silently=fail_silently)

Modified: django/branches/releases/1.0.X/tests/regressiontests/mail/tests.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/mail/tests.py  
2008-10-24 04:40:51 UTC (rev 9249)
+++ django/branches/releases/1.0.X/tests/regressiontests/mail/tests.py  
2008-10-24 04:41:58 UTC (rev 9250)
@@ -2,7 +2,9 @@
 r"""
 # Tests for the django.core.mail.
 
->>> from django.core.mail import EmailMessage
+>>> from django.conf import settings
+>>> from django.core import mail
+>>> from django.core.mail import EmailMessage, mail_admins, mail_managers
 >>> from django.utils.translation import ugettext_lazy
 
 # Test normal ascii character case:
@@ -60,4 +62,30 @@
 >>> email.message().as_string()
 'Content-Type: text/plain; charset="utf-8"\nMIME-Version: 
1.0\nContent-Transfer-Encoding: quoted-printable\nSubject: subject\nFrom: 
[EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 09 Nov 2001 01:08:47 
-\nMessage-ID: foo\n\ncontent'
 
+# Test that mail_admins/mail_managers doesn't connect to the mail server if 
there are no recipients (#9383)
+
+>>> old_admins = settings.ADMINS
+>>> old_managers = settings.MANAGERS
+>>> settings.ADMINS = []
+>>> settings.MANAGERS = []
+>>> mail.outbox = []
+>>> mail_admins('hi','there')
+>>> len(mail.outbox)
+0
+>>> mail.outbox = []
+>>> mail_managers('hi','there')
+>>> len(mail.outbox)
+0
+>>> settings.ADMINS = settings.MANAGERS = [('nobody','[EMAIL PROTECTED]')]
+>>> mail.outbox = []
+>>> mail_admins('hi','there')
+>>> len(mail.outbox)
+1
+>>> mail.outbox = []
+>>> mail_managers('hi','there')
+>>> len(mail.outbox)
+1
+>>> settings.ADMINS = old_admins
+>>> settings.MANAGERS = old_managers
+
 """


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty

2008-10-23 Thread Django

#9383: skip mail_admins/mail_managers if ADMINS or MANAGERS is empty
-+--
  Reporter:  adunar  | Owner:  nobody   
Status:  new | Milestone:  post-1.0 
 Component:  Core framework  |   Version:  1.0  
Resolution:  |  Keywords:  500 error mail_admins
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by mtredinnick):

 I'm not going to worry about the documentation change, since whether or
 not a network connection is made is an implementation detail. It doesn't
 affect user-visible functionality. I'm also dropping the change to
 `core/handlers/`, since the overhead isn't really significant and it's
 breaking encapsulation a bit (the code at that level doesn't care about
 `settings.ADMIN`; it just calls `mail_admins()` and is done with it).

 I've introduced an extra bit to the `EmailMessage` class so that it also
 doesn't create the network connection if there's no intended recipients.
 After all, that's really the more extensible interface for sending email,
 so we should be consistent and make it possible there. I've still kept the
 checks for `settings.ADMIN` and `settings.MANAGERS` in place, although
 it's a bit borderline. It's only two lines of code in each case and we
 already use the settings in those functions anyway.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9249 - django/branches/releases/1.0.X/django/conf

2008-10-23 Thread noreply


Author: mtredinnick
Date: 2008-10-23 23:40:51 -0500 (Thu, 23 Oct 2008)
New Revision: 9249

Modified:
   django/branches/releases/1.0.X/django/conf/global_settings.py
Log:
[1.0.X] Fixed #9410 -- I did not spell Portuguese correctly 18 months ago.
Fixed now. Thanks, kimus.

Backport of r9247 from trunk.


Modified: django/branches/releases/1.0.X/django/conf/global_settings.py
===
--- django/branches/releases/1.0.X/django/conf/global_settings.py   
2008-10-24 04:38:43 UTC (rev 9248)
+++ django/branches/releases/1.0.X/django/conf/global_settings.py   
2008-10-24 04:40:51 UTC (rev 9249)
@@ -76,7 +76,7 @@
 ('nl', gettext_noop('Dutch')),
 ('no', gettext_noop('Norwegian')),
 ('pl', gettext_noop('Polish')),
-('pt', gettext_noop('Portugese')),
+('pt', gettext_noop('Portuguese')),
 ('pt-br', gettext_noop('Brazilian Portuguese')),
 ('ro', gettext_noop('Romanian')),
 ('ru', gettext_noop('Russian')),


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9248 - in django/trunk: . django/core tests/regressiontests/mail

2008-10-23 Thread noreply


Author: mtredinnick
Date: 2008-10-23 23:38:43 -0500 (Thu, 23 Oct 2008)
New Revision: 9248

Modified:
   django/trunk/AUTHORS
   django/trunk/django/core/mail.py
   django/trunk/tests/regressiontests/mail/tests.py
Log:
Fixed #9383 -- Don't open a network connection for sending email if there's
nothing to send. Saves a bit of time when, for example, processing 500-error
emails with no ADMINs configured. Based on a patch from Jesse Young.


Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2008-10-24 04:37:51 UTC (rev 9247)
+++ django/trunk/AUTHORS2008-10-24 04:38:43 UTC (rev 9248)
@@ -423,6 +423,7 @@
 Jason Yan <[EMAIL PROTECTED]>
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
+Jesse Young <[EMAIL PROTECTED]>
 Jarek Zgoda <[EMAIL PROTECTED]>
 Cheng Zhang
 

Modified: django/trunk/django/core/mail.py
===
--- django/trunk/django/core/mail.py2008-10-24 04:37:51 UTC (rev 9247)
+++ django/trunk/django/core/mail.py2008-10-24 04:38:43 UTC (rev 9248)
@@ -268,6 +268,10 @@
 
 def send(self, fail_silently=False):
 """Sends the email message."""
+if not self.recipients():
+# Don't bother creating the network connection if there's nobody to
+# send to.
+return 0
 return self.get_connection(fail_silently).send_messages([self])
 
 def attach(self, filename=None, content=None, mimetype=None):
@@ -366,12 +370,16 @@
 
 def mail_admins(subject, message, fail_silently=False):
 """Sends a message to the admins, as defined by the ADMINS setting."""
+if not settings.ADMINS:
+return
 EmailMessage(settings.EMAIL_SUBJECT_PREFIX + subject, message,
  settings.SERVER_EMAIL, [a[1] for a in settings.ADMINS]
  ).send(fail_silently=fail_silently)
 
 def mail_managers(subject, message, fail_silently=False):
 """Sends a message to the managers, as defined by the MANAGERS setting."""
+if not settings.MANAGERS:
+return
 EmailMessage(settings.EMAIL_SUBJECT_PREFIX + subject, message,
  settings.SERVER_EMAIL, [a[1] for a in settings.MANAGERS]
  ).send(fail_silently=fail_silently)

Modified: django/trunk/tests/regressiontests/mail/tests.py
===
--- django/trunk/tests/regressiontests/mail/tests.py2008-10-24 04:37:51 UTC 
(rev 9247)
+++ django/trunk/tests/regressiontests/mail/tests.py2008-10-24 04:38:43 UTC 
(rev 9248)
@@ -2,7 +2,9 @@
 r"""
 # Tests for the django.core.mail.
 
->>> from django.core.mail import EmailMessage
+>>> from django.conf import settings
+>>> from django.core import mail
+>>> from django.core.mail import EmailMessage, mail_admins, mail_managers
 >>> from django.utils.translation import ugettext_lazy
 
 # Test normal ascii character case:
@@ -60,4 +62,30 @@
 >>> email.message().as_string()
 'Content-Type: text/plain; charset="utf-8"\nMIME-Version: 
1.0\nContent-Transfer-Encoding: quoted-printable\nSubject: subject\nFrom: 
[EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 09 Nov 2001 01:08:47 
-\nMessage-ID: foo\n\ncontent'
 
+# Test that mail_admins/mail_managers doesn't connect to the mail server if 
there are no recipients (#9383)
+
+>>> old_admins = settings.ADMINS
+>>> old_managers = settings.MANAGERS
+>>> settings.ADMINS = []
+>>> settings.MANAGERS = []
+>>> mail.outbox = []
+>>> mail_admins('hi','there')
+>>> len(mail.outbox)
+0
+>>> mail.outbox = []
+>>> mail_managers('hi','there')
+>>> len(mail.outbox)
+0
+>>> settings.ADMINS = settings.MANAGERS = [('nobody','[EMAIL PROTECTED]')]
+>>> mail.outbox = []
+>>> mail_admins('hi','there')
+>>> len(mail.outbox)
+1
+>>> mail.outbox = []
+>>> mail_managers('hi','there')
+>>> len(mail.outbox)
+1
+>>> settings.ADMINS = old_admins
+>>> settings.MANAGERS = old_managers
+
 """


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9247 - django/trunk/django/conf

2008-10-23 Thread noreply


Author: mtredinnick
Date: 2008-10-23 23:37:51 -0500 (Thu, 23 Oct 2008)
New Revision: 9247

Modified:
   django/trunk/django/conf/global_settings.py
Log:
Fixed #9410 -- I did not spell Portuguese correctly 18 months ago. Fixed now.
Thanks, kimus.


Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2008-10-22 23:14:48 UTC (rev 
9246)
+++ django/trunk/django/conf/global_settings.py 2008-10-24 04:37:51 UTC (rev 
9247)
@@ -76,7 +76,7 @@
 ('nl', gettext_noop('Dutch')),
 ('no', gettext_noop('Norwegian')),
 ('pl', gettext_noop('Polish')),
-('pt', gettext_noop('Portugese')),
+('pt', gettext_noop('Portuguese')),
 ('pt-br', gettext_noop('Brazilian Portuguese')),
 ('ro', gettext_noop('Romanian')),
 ('ru', gettext_noop('Russian')),


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9411: Test added in [9081] fails on MySQL

2008-10-23 Thread Django

#9411: Test added in [9081] fails on MySQL
+---
  Reporter:  kmtracey   | Owner:  mtredinnick
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by mtredinnick):

 No, if it doesn't just work out of the box (i.e. if it requires a "SET..."
 call), there's no point in worrying about it. That's extra overhead we can
 avoid.

 I'll work around the representation issue, but I was being hopeful on the
 other front (who in their right mind uses backticks as a distinguished
 marker?! We learnt the error of that approach with sub-processes in Unix
 shells about 15 years ago, long before MySQL was on the scene).

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3414: middleware/common.py and SCGI bug - string index out of range (caused by missing PATH_INFO)

2008-10-23 Thread Django

#3414: middleware/common.py and SCGI bug - string index out of range (caused by
missing PATH_INFO)
---+
  Reporter:  Piotr Maliński <[EMAIL PROTECTED]>  | Owner:  
nobody
Status:  closed| Milestone: 
   
 Component:  Core framework|   Version:  
SVN   
Resolution:  fixed |  Keywords: 
   
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 Posting to a closed ticket is a good way to make sure a comment gets
 overlooked. Fortunately, in this case I saw it go by, so I've opened #9435
 to make sure any inconsistencies are tidied up.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9411: Test added in [9081] fails on MySQL

2008-10-23 Thread Django

#9411: Test added in [9081] fails on MySQL
+---
  Reporter:  kmtracey   | Owner:  mtredinnick
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Looks like `SET sql_mode='ANSI_QUOTES';` can be used to switch to double-
 quotes-signifies-identifier, single-quotes-signifies-string mode:

 http://dev.mysql.com/doc/refman/5.0/en/identifiers.html

 It's in the 3.23/4.0/4.1 version of the manual as well so it seems to be
 available far back.  So it appears we could change the mysql backend to be
 more consistent with the others in this area.

 But...it's potentially a backwards-incompatible change for anyone with raw
 SQL queries in their Django app code who has used double-quotes to signify
 strings (I'm thinking hardcoded ones, so not going through any kind of
 backend auto-quoting), since in the default mode you can quote strings
 with either single or double quotes.  After switching the mode to
 ansi_quotes these queries would start failing.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9433: File locking broken on AFP mounts

2008-10-23 Thread Django

#9433: File locking broken on AFP mounts
---+
  Reporter:  rndblnch  | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 We're not going to revert that change for one particular sort of
 filesystem on one particular operating system, since it fixes a much
 broader class of problems. That would be very counter-productive.

 So the real solution here is coming up with a way to work out when that
 locking attempt won't work. Since we're using the recommended approach to
 file locking, file systems that don't support it will need specific
 workarounds (or a warning saying one can't use them for that purpose).
 Assuming POSIX-like behaviour is quite valid, but exceptional handling for
 edge-cases is reasonable if we can detect them.

 You have one of these filesystems available. So can you look up how we can
 detect the problem? Does `flock()` work in those cases and, if so, is it
 possible to try `lockf()` and, if that fails, fall back to `flock()`? Do
 some experiments and see what you can come up with.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9435: Check out behaviour of wsgi backend with PATH_INFO being an empty string

2008-10-23 Thread Django

#9435: Check out behaviour of wsgi backend with PATH_INFO being an empty string
-+--
  Reporter:  mtredinnick | Owner:  mtredinnick
Status:  assigned| Milestone: 
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords: 
 Stage:  Unreviewed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I want to make sure we at least look at this. It may or may not be an
 actual issue, since Django's URL resolver doesn't care about the leading
 '/'; it just treats it as a separator and there must be some kind of
 "first character" in the URL. So I suspect it's probably not actually
 causing any misbehaviour and we're just ensuring the `PATH_INFO`
 equivalent is in a reasonably normalised form. However, we should make
 sure that the reported information (via `request.path_info`) matches
 reality, which may be an empty string, so that means differentiating
 between our internal normalised version and the upstream passed-in
 version.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9435: Check out behaviour of wsgi backend with PATH_INFO being an empty string

2008-10-23 Thread Django

#9435: Check out behaviour of wsgi backend with PATH_INFO being an empty string
+---
 Reporter:  mtredinnick |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Transferring a side-issue from #3414 (comment 23 over there):

 Note: the WSGI spec allows PATH_INFO to be empty or missing; specifically:

 "This may be an empty string, if the request URL targets the application
 root and does NOT have a trailing slash." (emph. added)

 And WSGI servers are allowed to omit PATH_INFO (and various other
 variables) if they are an empty string.

 IIUC, this means that [8105] doesn't correctly handle the case where
 someone goes to "foo.com/django" (no trailing '/'), because it wrongly
 assumes that a missing PATH_INFO is a '/'. Per the WSGI spec, a missing
 PATH_INFO is in fact an empty string. That means that relative URLs at the
 root of a Django site would not work correctly under servers that omit an
 empty PATH_INFO.

 Whether the OP issue here is a configuration problem is irrelevant to this
 piece: it is perfectly legal for a WSGI server to omit PATH_INFO if it's
 an empty string, and its omission means that it's an EMPTY string, not a
 '/'.

 Conversely, if a WSGI server is ommitting PATH_INFO when PATH_INFO should
 be a "/" (i.e. the URL was "foo.com/django/" with a trailing "/"), then
 that server is seriously broken and should be fixed. (But I'm not seeing
 anything here that suggests this is actually the case.)

 Either way, however, the code that's defaulting a missing PATH_INFO to "/"
 appears to be quite wrong: either creating a bug or masking one somewhere
 else.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9422: Incorrect handling of foreign keys by serializers

2008-10-23 Thread Django

#9422: Incorrect handling of foreign keys by serializers
+---
  Reporter:  etianen| Owner:  mtredinnick
Status:  assigned   | Milestone: 
 Component:  Serialization  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 You forgot to include the patch to the test cases that fails beforehand
 and works afterwards. :-)

 Also, I think this is more symptomatic of a larger problem that was sort
 of hacked around in r8957. Trying to fix that properly has shown it
 extends further than just that (particularly once you start chaining
 multiple foreign key references together, not just one level deep).

 Definitely a bug here, but I'm not convinced that this is quite the right
 fix for 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

2008-10-23 Thread Django

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
---+
  Reporter:  adamnelson| Owner:  adamnelson
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:  mysql 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 I already have the patch for it although what I'd like to do is to just
 make MySQL 5.0 a minimum requirement for Django 1.0 so that the check in
 validate.py only has to check for that one scenario of varchar > 255 AND
 unique on the same column rather than bothering with the varchar > 255
 generally which is really only a problem for MySQL 4.1 and earlier.

 On a side note, I was going to ignore the fact that MyISAM tables could
 possible handle 300 something bytes in a similar situation since the
 amount is determined by the size of the overall table structure - would be
 exceedingly difficult to test ahead of time.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9413: naming a template tag library the same as an app causes import problems

2008-10-23 Thread Django

#9413: naming a template tag library the same as an app causes import problems
+---
  Reporter:  akaihola   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 This is a symptom of #6587.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9405: [patch] DatabaseOperations should track its own connection

2008-10-23 Thread Django

#9405: [patch] DatabaseOperations should track its own connection
---+
  Reporter:  Tarken| Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:  wontfix   |  Keywords:  multiple 
database
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 I don't think this is a necessary change at the moment. It's not
 immediately clear that it's the right approach for multiple database
 support. The `DatabaseOperations` class only exists inside a
 `DatabaseWrapper` class, so there's no confusion about whether it's the
 right type or not. It shouldn't be doing anything that requires access to
 an active connection.

 Introspection and creation are quite different, one-off operations that
 need to actually talk to the database. They are more comparable to
 `DatabaseWrapper` than `DatabaseOperations`.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9411: Test added in [9081] fails on MySQL

2008-10-23 Thread Django

#9411: Test added in [9081] fails on MySQL
+---
  Reporter:  kmtracey   | Owner:  mtredinnick
Status:  assigned   | Milestone: 
 Component:  Uncategorized  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Does MySQL require this somewhat nutty backtick quoting? It's pretty
 unreadable in general and if it can use double-quotes, we should just
 change it to be like all the other database backends.

 But, yeah, I can rewrite the test. Probably if it runs correctly (i.e. if
 the query executes) it's sufficient, so I could just run it against the
 database.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9406: Query.as_sql() generates invalid ORDER BY clause

2008-10-23 Thread Django

#9406: Query.as_sql() generates invalid ORDER BY clause
---+
  Reporter:  egenix_viktor | Owner:  
mtredinnick  
Status:  assigned  | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  Query 
as_sql ORDER clause ordering duplicate wrong SQL generate generates
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 Nice catch. Looks like bad SQL indeed.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9400: flock causes problems when writing to an NFS share

2008-10-23 Thread Django

#9400: flock causes problems when writing to an NFS share
+---
  Reporter:  mikeh  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 So we're in an impossible situation here then. `lockf()` doesn't work
 everywhere, `flock()` doesn't work everywhere. And there's no way to know
 which one works.

 Since `lockf()` -- the way Django currently does things -- is the
 recommended approach to doing portable locking and it should work with NFS
 (I made sure and read the Python source before making the change), I'm
 inclined to leave the current behaviour in place until a more robust
 solution emerges.

 Thus, we'll need more information and investigation from you on this one.
 For example, does changing the `lockf()` call to `flock()` also fail? Do
 you have `statd` running on the server (so that locking is available --
 since that was one of the problems in a Debian case, for example)? What
 information can you track down about why one version works somewhere and
 the other version works (if it does) on other NFS servers? What's the
 differentiating feature?

 Sorry to push the research back in your direction, but right now Django's
 doing the best it can as far as following recommended practices and the
 current code certainly avoided the problems that were reported earlier.
 Yours is the first case that's been reported of it not working on a
 reliable NFS setup with the current code, so you have the (only?) failing
 test case and will need to work out what's going on. I'm far beyond being
 able to guess.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9397: weird HttpResponseRedirect reaction to url

2008-10-23 Thread Django

#9397: weird HttpResponseRedirect reaction to url
+---
  Reporter:  billychasen| Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Old description:

> If I have a url defined, such as:
>
> (r'^hello$', 'mysite.index.views.hello')
>
> and let's say I have a page on http://mysite.net that redirects via
> HttpResponseRedirect(reverse('mysite.index.views.hello'))
>
> If I am at http://www.mysite.net -- it correctly goes to
> http://www.mysites.net/hello
> If I am at http://mysite.net (no www) -- it redirects to
> http://mysite.net/.net/hello
>
> It's easily fixed by changing the url definition to
>
> (r'^hello/$', 'mysite.index.views.hello')  (adding a trailing forward
> slash)
>
> Seems to me though, that this shouldn't be required (seems a little buggy
> and took awhile to track down)

New description:

 If I have a url defined, such as:
 {{{
 (r'^hello$', 'mysite.index.views.hello')
 }}}
 and let's say I have a page on http://mysite.net that redirects via
 `HttpResponseRedirect(reverse('mysite.index.views.hello'))`

 If I am at `http://www.mysite.net` -- it correctly goes to
 `http://www.mysites.net/hello`

 If I am at `http://mysite.net` (no www) -- it redirects to
 `http://mysite.net/.net/hello`

 It's easily fixed by changing the url definition to

 {{{
 (r'^hello/$', 'mysite.index.views.hello')
 }}}
 (adding a trailing forward slash)

 Seems to me though, that this shouldn't be required (seems a little buggy
 and took awhile to track down)

Comment (by mtredinnick):

 (Fixed description formatting to stop my eyes watering.)

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9392: Inherited model fields being duplicated in Forms

2008-10-23 Thread Django

#9392: Inherited model fields being duplicated in Forms
+---
  Reporter:  terpsquared| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 Looks like a dupe of #9393.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9393: Overridden inherited model fields being duplicated in forms

2008-10-23 Thread Django

#9393: Overridden inherited model fields being duplicated in forms
+---
  Reporter:  terpsquared| Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mtredinnick):

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

Comment:

 This is a bug, but not the one you're thinking of. It's a bug that
 duplicated model field names aren't explicitly flagged as errors in
 validation. There are far too many things that can go wrong when
 duplicating fields like this.

 I'm going to close this as a duplicate of #8886, since that's describing
 another symptom of the same problem.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9381: Errors in django.contib.auth PasswordResetTest

2008-10-23 Thread Django

#9381: Errors in django.contib.auth PasswordResetTest
-+--
  Reporter:  kit1980 | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Authentication  |   Version:  SVN 
Resolution:  invalid |  Keywords:  PasswordResetTest, tests
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 I don't believe this patch is necessary. The current regular expression
 looks like it works as intended. `\S` matches all non-whitespace
 characters. If I pass in the string you give, it returns the token and
 everything, as one would expect.

 {{{
 #!python
 >>> re.search(r"https?://[^/]*(/.*reset/\S*)", "Please confirm
 http://127.0.0.1:8000/accounts/password/reset/1-271-fc1325747eabe02fab7e/
 Thanks!").groups()
 ('/accounts/password/reset/1-271-fc1325747eabe02fab7e/',)
 }}}

 So you have perhaps left something out of the steps you took to see the
 problem in the first place. Ideally, a patch against Django's tests that
 shows the failure would help, but, failing that, at least some steps to
 take to repeat the problem in a rapid fashion.

 Closing for now, since I really cannot see what the problem is here. If
 you can still repeat the problem, please reopen with some more details.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9376: Support initial values for clean() not just for FileField

2008-10-23 Thread Django

#9376: Support initial values for clean() not just for FileField
-+--
  Reporter:  aszlig  | Owner:  nobody 
Status:  closed  | Milestone: 
 Component:  Forms   |   Version:  SVN
Resolution:  wontfix |  Keywords:  form fields
 Stage:  Unreviewed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 This is the sort of specialised use-case that is best done in the custom
 form field's initialisation and/or cleaning methods. You have complete
 control over what is displayed and stored in the field class. Just
 subclass `__init__` appropriately; this doesn't need any modifications on
 the Field class.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8874: problem with URLs on FastCGI after update to 1.0

2008-10-23 Thread Django

#8874: problem with URLs on FastCGI after update to 1.0
-+--
  Reporter:  kyprizel| Owner:  kyprizel
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.0 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

  * stage:  Design decision needed => Accepted

Comment:

 (Moving out of design decision needed, since this is either a bug or not.
 If it's a bug, we should fix it. There's no design decision needed, just a
 proper understanding and solution.)

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8874: problem with URLs on FastCGI after update to 1.0

2008-10-23 Thread Django

#8874: problem with URLs on FastCGI after update to 1.0
-+--
  Reporter:  kyprizel| Owner:  kyprizel
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.0 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by mtredinnick):

 I don't believe this patch is really fixing the root problem. It looks
 like it's forcing script name to an incorrect value and just kind of works
 by accident.

 The real question here is why does script name have a value of
 `feedback/`? That looks like either a configuration bug or a bug in nginx
 or something. We need to understand that a bit better before working out a
 solution to this problem.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9434: mod_python and unique PythonInterpreters

2008-10-23 Thread Django

#9434: mod_python and unique PythonInterpreters
+---
  Reporter:  lifewithryan   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by lifewithryan):

 Thats EXACTLY it.  IP based virtual hosts (actually only listening on
 localhost ports 8080 and 8081).  So adding the PythonInterpreter directive
 worked.  The docs just didn't mention that.  (So naturally I got chastised
 in the IRC channel for even askin...but i"m used to that).

 Might be something we want to add that to the docs.  But thanks for the
 info, you've verified what I discovered today.  Thanks

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

2008-10-23 Thread Django

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
---+
  Reporter:  adamnelson| Owner:  adamnelson
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:  mysql 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * stage:  Unreviewed => Accepted
  * component:  Core framework => Database layer (models, ORM)
  * milestone:  post-1.0 =>

Comment:

 Russell, adding the unique index limits things further on MySQL (it avoids
 creating indexes over arbitrarily wide columns). See
 [http://groups.google.com/group/django-
 developers/browse_frm/thread/edf3312c4fa1d2d4# this thread on django-dev]
 for details. We should add some extra validation for that case for MySQL,
 as well as add a note to the docs for !CharField for people developing on
 other database backends who want their code to also be portable to 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9434: mod_python and unique PythonInterpreters

2008-10-23 Thread Django

#9434: mod_python and unique PythonInterpreters
+---
  Reporter:  lifewithryan   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by grahamd):

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

Comment:

 What probably matters is whether the virtual hosts are distinguished by
 server name. If the virtual hosts are for the same server name but on
 different ports, then there may be an issue. This is because mod_python
 defaults to naming sub interpreter based on server name only and doesn't
 use the port. Thus two virtual hosts on different ports with same server
 name will shared same sub interpreter. Another mistake which can also
 cause mod_python to appear to share sub interpreters across virtual hosts,
 is not defining NameVirtualHost directive in Apache configuration.

 So it is clear how your system is setup, provide how your virtual hosts
 are configured.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

2008-10-23 Thread Django

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
-+--
  Reporter:  adamnelson  | Owner:  adamnelson
Status:  new | Milestone:  post-1.0  
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:  mysql 
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by russellm):

 ./manage.py validate already throws a validation warning if the MySQL
 version is less than 5.0.3 (which is the version at which the character
 limit ceased to be a problem). I know it does this because I hit this
 warning just last week. The validation is done
 
[http://code.djangoproject.com/browser/django/trunk/django/db/backends/mysql/validation.py
 here].

 Have you actually seen this problem somewhere with a system configuration
 that we're not catching? You don't provide a Django model or details on
 exactly what you are doing, so it's difficult to tell how you actually
 encountered this problem.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6148: Add generic support for database schemas

2008-10-23 Thread Django

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner: 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by gabor):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3414: middleware/common.py and SCGI bug - string index out of range (caused by missing PATH_INFO)

2008-10-23 Thread Django

#3414: middleware/common.py and SCGI bug - string index out of range (caused by
missing PATH_INFO)
---+
  Reporter:  Piotr Maliński <[EMAIL PROTECTED]>  | Owner:  
nobody
Status:  closed| Milestone: 
   
 Component:  Core framework|   Version:  
SVN   
Resolution:  fixed |  Keywords: 
   
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by pje):

 Note: the WSGI spec allows PATH_INFO to be empty or missing; specifically:

 "This may be an empty string, if the request URL targets the application
 root and does NOT have a trailing slash." (emph. added)

 And WSGI servers are allowed to omit PATH_INFO (and various other
 variables) if they are an empty string.

 IIUC, this means that [8105] doesn't correctly handle the case where
 someone goes to "foo.com/django" (no trailing '/'), because it wrongly
 assumes that a missing PATH_INFO is a '/'.  Per the WSGI spec, a missing
 PATH_INFO is in fact an empty string.  That means that relative URLs at
 the root of a Django site would not work correctly under servers that omit
 an empty PATH_INFO.

 Whether the OP issue here is a configuration problem is irrelevant to this
 piece: it is perfectly legal for a WSGI server to omit PATH_INFO if it's
 an empty string, and its omission means that it's an EMPTY string, not a
 '/'.

 Conversely, if a WSGI server is ommitting PATH_INFO when PATH_INFO should
 be a "/" (i.e. the URL was "foo.com/django/" with a trailing "/"), then
 that server is seriously broken and should be fixed.  (But I'm not seeing
 anything here that suggests this is actually the case.)

 Either way, however, the code that's defaulting a missing PATH_INFO to "/"
 appears to be quite wrong: either creating a bug or masking one somewhere
 else.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9433: File locking broken on AFP mounts

2008-10-23 Thread Django

#9433: File locking broken on AFP mounts
--+-
 Reporter:  rndblnch  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 File locking does not work on volumes mounted using AFP on Mac OS X 10.5

 django/core/files/locks.py assumes that the presence of fcntl module
 implies a posix system and that for a posix system fcntl.lockf works for
 every file accessible on the file system.
 This is not the case on a Mac OS X box for files on a volume mounted using
 AFP:

 {{{
 [taquet:~] iihm% uname -mprs
 Darwin 9.5.0 Power Macintosh powerpc
 [taquet:~] iihm% python
 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:16)
 [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import django
 >>> django.VERSION
 (1, 0, 'final')
 >>> from django.core.files import locks
 >>> f = open("/Volumes/Web/test.txt", "w")
 >>> locks.lock(f, locks.LOCK_EX)
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Library/Python/2.5/site-packages/django/core/files/locks.py",
 line 57, in lock
 fcntl.lockf(fd(file), flags)
 IOError: [Errno 45] Operation not supported
 }}}

 A workaround is to revert [8675].
 I know this is not acceptable since it fixes #8403, but it is still a fact
 that from a Mac OS X user perspective, [8675] introduce a regression.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9432: Negation operator missing from Q Objects documentation

2008-10-23 Thread Django

#9432: Negation operator missing from Q Objects documentation
---+
 Reporter:  dchandek   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/topics/db/queries/#complex-lookups-
 with-q-objects

 The documentation should state that the unary negation operator "~" can be
 used on a Q object.

 The "see also" note which links to
 
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/or_lookups/models.py
 does provide an example usage of the negation operator.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9039: Form validation problem for model with ForeignKey having unique=True, blank=True, null=True

2008-10-23 Thread Django

#9039: Form validation problem for model with ForeignKey having
unique=True,blank=True,null=True
---+
  Reporter:  nategriswold  | Owner:  kmtracey
Status:  reopened  | Milestone:  
 Component:  Forms |   Version:  1.0 
Resolution:|  Keywords:  model-validation
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 Yeah, that makes the most sense to me as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9025: Nested Inline Support in Admin

2008-10-23 Thread Django

#9025: Nested Inline Support in Admin
---+
  Reporter:  pixelcort | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Fugazi):

  * component:  Contrib apps => django.contrib.admin

Comment:

 anybody can fix 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

2008-10-23 Thread Django

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
--+-
   Reporter:  adamnelson  |Owner:  adamnelson
 Status:  new |Milestone:  post-1.0  
  Component:  Core framework  |  Version:  1.0   
   Keywords:  mysql   |Stage:  Unreviewed
  Has_patch:  0   |   Needs_docs:  0 
Needs_tests:  0   |   Needs_better_patch:  0 
--+-
 == Description ==

 MySQL 5.0 can't handle 256 or more characters on a column with a UNIQUE
 index if the storage engine is InnoDB and the character set is utf8

 == Test ==

 Shows 1 byte character set working:
 {{{
 mysql> create table foo ( x varchar(999), primary key (x)) character set
 = 'latin1';
 Query OK, 0 rows affected (0.00 sec)
 }}}
 Shows failure with larger character set (standard python utf8):
 {{{
 mysql> create table foo2 ( x varchar(999), primary key (x)) character
 set = 'utf8';
 ERROR 1071 (42000): Specified key was too long; max key length is 999
 bytes
 }}}
 Shows success that works with utf8:
 {{{
 mysql> create table foo2 ( x varchar(255), primary key (x)) character
 set = 'utf8';
 Query OK, 0 rows affected (0.01 sec)
 }}}

 == Suggested Fix ==

 ./manage.py validate should throw a validation warning if the database is
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9430: Writing Views makes reference to previously mentioned issue but doesn't say where

2008-10-23 Thread Django

#9430: Writing Views makes reference to previously mentioned issue but doesn't 
say
where
---+
 Reporter:  wyleu  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/topics/http/views/

 to quote:

 Returning HTTP error codes in Django is easy. We've already mentioned the
 HttpResponseNotFound, HttpResponseForbidden, HttpResponseServerError,
 etc., subclasses; just return an instance of one of those subclasses
 instead of a normal HttpResponse in order to signify an error. For
 example:


 It says we've already mentioned but it would be useful if their were a
 pointer to where these errors are first mentioned. I came at this from a
 methodical reading of the view documentation and felt that their should
 have been some indication as to where these objects were first introduced.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9429: Comment.get_as_text returns no information about non-authenticated users

2008-10-23 Thread Django

#9429: Comment.get_as_text returns no information about non-authenticated users
-+--
 Reporter:  Kjell Magne Fauske   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The {{{get_as_text method}}} in
 {{{django.contrib.comments.models.Comments}}} uses the {{{self.user}}}
 field when inserting information about the commenter. This field will be
 set to {{{None}}} for non-authenticated users. The {{{name}}} property
 should be used instead since it checks that a user is authenticated or not
 and returns the correct name in both cases.

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9204: Google Maps Marker to change the Icon

2008-10-23 Thread Django

#9204: Google Maps Marker to change the Icon
-+--
  Reporter:  qingfeng| Owner:  jbronn   
  
Status:  new | Milestone:  post-1.0 
  
 Component:  GIS |   Version:  1.0  
  
Resolution:  |  Keywords:  geodjango google map icon 
gicon
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by qingfeng):

 This is a new patch:), add `GIcon` and doctest

 {{{
 >>> GIcon("http://gmaps-
 samples.googlecode.com/svn/trunk/markers/blue/blank.png")
 

 >>> "%s"%GIcon("http://gmaps-
 samples.googlecode.com/svn/trunk/markers/blue/blank.png")
 'icon: eval("icon=new GIcon(G_DEFAULT_ICON);icon.image=\'http://gmaps-
 samples.googlecode.com/sv
 n/trunk/markers/blue/blank.png\';icon")'
 }}}

-- 
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

41 matches

Mail list logo