Re: [Django] #10779: Typo in Files documentation

[Django]

#10779: Typo in Files documentation
+---
  Reporter:  amiroff| Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  typo, documentation
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by amiroff):

  * needs_better_patch:  => 0
  * version:  1.0 => SVN
  * 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
-~--~~~~--~~--~--~---

Re: [Django] #10814: management loaddata with verbosity > 0 fails silently under WSGI

[Django]

#10814: management loaddata with verbosity > 0 fails silently under WSGI
-+--
  Reporter:  yourcelf| Owner:  nobody   

Status:  closed  | Milestone:   

 Component:  Core framework  |   Version:  SVN  

Resolution:  wontfix |  Keywords:  management 
loaddata verbosity stdout wsgi
 Stage:  Design decision needed  | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 I concur with James. The management commands write to stdout, pretty much
 by definition. WSGI, again pretty much by definition, doesn't like scripts
 to write to stdout. This is one of those "Doctor, it hurts when I do X";
 "Then don't do X" situations.

 @grahamd - Errors are already written to stderr; writing notifications and
 other progress output to stderr isn't appropriate behavior for the normal
 use case - calling the management command from the command line.
 verbosity=0 exists for situations where you don't want terminal output
 from management commands.

-- 
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] #10814: management loaddata with verbosity > 0 fails silently under WSGI

[Django]

#10814: management loaddata with verbosity > 0 fails silently under WSGI
-+--
  Reporter:  yourcelf| Owner:  nobody   

Status:  new | Milestone:   

 Component:  Core framework  |   Version:  SVN  

Resolution:  |  Keywords:  management 
loaddata verbosity stdout wsgi
 Stage:  Design decision needed  | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

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

 (and perhaps the proper solution here would really be to add documentation
 on calling commands in this fashion, warning people to set verbosity to 0
 or redirect stdout)

-- 
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] #10814: management loaddata with verbosity > 0 fails silently under WSGI

[Django]

#10814: management loaddata with verbosity > 0 fails silently under WSGI
-+--
  Reporter:  yourcelf| Owner:  nobody   

Status:  new | Milestone:   

 Component:  Core framework  |   Version:  SVN  

Resolution:  |  Keywords:  management 
loaddata verbosity stdout wsgi
 Stage:  Design decision needed  | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Changes (by ubernostrum):

  * stage:  Unreviewed => Design decision needed

Comment:

 Personally I'm inclined toward wontfix on this one, for a few reasons:

 1. Management commands are typically designed to be invoked via the
 command line or, in some cases, as cron jobs. While you ''can'' invoke
 them from web requests, that's not really the use case they primarily
 target.

 2. Even if we were to decide to work around this in some fashion, we'd be
 left with a glaring problem: there's no way to tell (AFAIK), from inside
 the management command, that it's been invoked during processing of a
 request through WSGI.

 3. It's easy enough to just dial down the verbosity as your situation
 warrants.

-- 
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] #9559: CSRFMiddleware should strip POST dat instead of showing the user an error message if a forgery is detected

[Django]

#9559: CSRFMiddleware should strip POST dat instead of showing the user an error
message if a forgery is detected
-+--
  Reporter:  zain| Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Contrib apps|   Version:  1.0  
   
Resolution:  |  Keywords:  csrf, 
csrfmiddleware
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  1   |  
-+--
Changes (by Glenn):

 * cc: glennfmayn...@gmail.com (added)

Comment:

 If you're expecting an external website to POST data at a specific page on
 yours, shouldn't you @csrf_view_exempt the view it's returning to?

 I guess it would help for contrib.csrf to expose a way to check a request
 manually, so you can @csrf_view_exempt a view and then handle a failed
 CSRF check some other way.  This would make it easy to implement things
 like @csrf_view_clear_post, too.

-- 
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] #10816: CsrfMiddleware false positive after session.flush()

[Django]

#10816: CsrfMiddleware false positive after session.flush()
---+
 Reporter:  Glenn  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Contrib apps   | Version:  SVN   
 Keywords:  csrf sessions  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If a user loads a form, logs in in another window, and then submits the
 form, CSRF triggers.  The same happens if you're on a page with a form,
 click a login button, and then browse back to the form and submit it.  The
 same also happens if the user logs out and then logs in as a different
 user, and submits an old form.

 This happens because contrib.auth.login and logout reset the session,
 which changes the CSRF security token.

 (Is submitting a form in this situation a good idea?  That's up to the
 site; CsrfMiddleware should not cause forms to fail in non-CSRF
 situations.)

 CSRFMiddleware should set its own random cookie, independent of the
 session cookie, and leave it there indefinitely; the CSRF cookie in a form
 will always remain valid, regardless of the session.  (This will also have
 the side-effect of making CSRF not depend on sessions, which doesn't
 hurt.)

 I can implement this, but I'll wait for feedback first.

-- 
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] #10815: improved description for accessing foreign keys in templates

[Django]

#10815: improved description for accessing foreign keys in templates
+---
  Reporter:  paulbury   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:  foreign key, templates
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by paulbury):

  * needs_better_patch:  => 0
  * 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] #10815: improved description for accessing foreign keys in templates

[Django]

#10815: improved description for accessing foreign keys in templates
+---
 Reporter:  paulbury|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.0   
 Keywords:  foreign key, templates  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Looked high and low for examples of how to do this in the documentation to
 no avail. I eventually found the following article:
 http://lowkster.blogspot.com/2008/01/getting-to-pesky-foreign-key-data-
 in.html

 it was excellent and exactly what i would have liked to see in your doco
 (or something similar). Thought it was worth passing on for future
 improvements to the documentation.

-- 
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] #10529: Generic Inline fails (unexpected keyword argument `prefix`)

[Django]

#10529: Generic Inline fails (unexpected keyword argument `prefix`)
-+--
  Reporter:  leitjohn| Owner:  leitjohn
Status:  closed  | Milestone:  
 Component:  Forms   |   Version:  SVN 
Resolution:  invalid |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 Your checkout is somehow incorrect, if you consult the source code in the
 repo it clearly accepts a preifx argument.

-- 
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] #10529: Generic Inline fails (unexpected keyword argument `prefix`)

[Django]

#10529: Generic Inline fails (unexpected keyword argument `prefix`)
-+--
  Reporter:  leitjohn| Owner:  leitjohn
Status:  reopened| Milestone:  
 Component:  Forms   |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by earthman):

 admin.py -> http://dpaste.com/33493/

 URL: localhost:8000/admin/tracker/action/34/

 Traceback:
 {{{
 Environment:

 Request Method: GET
 Request URL: http://localhost:8000/admin/tracker/action/34/
 Django Version: 1.1 beta 1
 Python Version: 2.5.4
 Installed Applications:
 ['django.contrib.admin',
  'django.contrib.auth',
  'django.contrib.comments',
  'django.contrib.contenttypes',
  'django.contrib.markup',
  'django.contrib.sessions',
  'django.contrib.sites',
  'trackera.tracker',
  'trackera.common']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.middleware.doc.XViewMiddleware')


 Traceback:
 File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in
 get_response
   92. response = callback(request, *callback_args,
 **callback_kwargs)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in root
   480. return self.model_page(request, *url.split('/', 2))
 File "C:\Python25\Lib\site-packages\django\views\decorators\cache.py" in
 _wrapped_view_func
   44. response = view_func(request, *args, **kwargs)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" in
 model_page
   499. return admin_obj(request, rest_of_url)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
 __call__
   1092. return self.change_view(request, unquote(url))
 File "C:\Python25\Lib\site-packages\django\db\transaction.py" in
 _commit_on_success
   240. res = func(*args, **kw)
 File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in
 change_view
   844. formset = FormSet(instance=obj, prefix=prefix)

 Exception Type: TypeError at /admin/tracker/action/34/
 Exception Value: __init__() got an unexpected keyword argument 'prefix'
 }}}

-- 
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] #10529: Generic Inline fails (unexpected keyword argument `prefix`)

[Django]

#10529: Generic Inline fails (unexpected keyword argument `prefix`)
-+--
  Reporter:  leitjohn| Owner:  leitjohn
Status:  reopened| Milestone:  
 Component:  Forms   |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by earthman):

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

Comment:

 I am receiving the same error after upgrading to trunk on Windows and on
 Unix...with inline forms.

 Was there a solution found/proposed to this issue?

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

Re: [Django] #1371: defining default settings for apps

[Django]

#1371: defining default settings for apps
+---
  Reporter:  dja...@poelzi.org  | Owner:  adrian
Status:  closed | Milestone:
 Component:  Core framework |   Version:  SVN   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gonz):

 * cc: gonz (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] #10814: management loaddata with verbosity > 0 fails silently under WSGI

[Django]

#10814: management loaddata with verbosity > 0 fails silently under WSGI
-+--
  Reporter:  yourcelf| Owner:  nobody   

Status:  new | Milestone:   

 Component:  Core framework  |   Version:  SVN  

Resolution:  |  Keywords:  management loaddata 
verbosity stdout wsgi
 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:

 The command should be changed to redirect stdout to stderr if you cannot
 actually change loaddata to print debug messages to stderr.

 Ultimately in mod_wsgi 3.0 I have given up trying to encourage people to
 write portable WSGI application code.

 See:

   http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-
 output.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] #10363: ModelForm excluded field can still be updated

[Django]

#10363: ModelForm excluded field can still be updated
+---
  Reporter:  jgoldberg  | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Forms  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Accepted => Ready for checkin

-- 
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] #10163: Admin view redirection failures

[Django]

#10163: Admin view redirection failures
+---
  Reporter:  Vinay Sajip   | Owner:  
nobody
Status:  reopened   | Milestone:  
1.1   
 Component:  Forms  |   Version:  
SVN   
Resolution: |  Keywords:  
admin view redirection
 Stage:  Accepted   | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * has_patch:  0 => 1

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

Re: [Django] #10134: unique_for_* broken?

[Django]

#10134: unique_for_* broken?
---+
  Reporter:  wdoekes   | Owner:  Alex   
 
Status:  new   | Milestone:  1.1
 
 Component:  Forms |   Version:  SVN
 
Resolution:|  Keywords:  unique_for_date 
unique_for_month unique_for_year
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * has_patch:  0 => 1

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

Re: [Django] #10704: ifchanged-else documentation lost in r8506

[Django]

#10704: ifchanged-else documentation lost in r8506
+---
  Reporter:  Tarken | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Accepted => Ready for checkin

-- 
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] #10812: Slight documentation inconsistency in querysets.txt

[Django]

#10812: Slight documentation inconsistency in querysets.txt
+---
  Reporter:  uzi| Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * 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
-~--~~~~--~~--~--~---

Re: [Django] #10567: Slovak translation update

[Django]

#10567: Slovak translation update
---+
  Reporter:  mandre| Owner:  nobody
Status:  closed| Milestone:  1.1   
 Component:  Translations  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 I think it is better idea to use 'elektronickou poštou' (old) than
 'e-mailom' (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] #10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with GeoQueryset

[Django]

#10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with
GeoQueryset
---+
  Reporter:  bretthoerner  | Owner:
Status:  closed| Milestone:  1.1   
 Component:  GIS   |   Version:  1.1-beta-1
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

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

Comment:

 (In [10559]) Fixed #10807 - `GeoWhereNode` no longer passes `Constraint`
 objects to where they shouldn'"'"'t go.

-- 
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] r10559 - in django/trunk/django/contrib/gis: db/models/sql tests/relatedapp

[noreply]

Author: jbronn
Date: 2009-04-14 14:14:32 -0500 (Tue, 14 Apr 2009)
New Revision: 10559

Modified:
   django/trunk/django/contrib/gis/db/models/sql/where.py
   django/trunk/django/contrib/gis/tests/relatedapp/tests.py
Log:
Fixed #10807 - `GeoWhereNode` no longer passes `Constraint` objects to where 
they shouldn't go.   


Modified: django/trunk/django/contrib/gis/db/models/sql/where.py
===
--- django/trunk/django/contrib/gis/db/models/sql/where.py  2009-04-13 
15:16:17 UTC (rev 10558)
+++ django/trunk/django/contrib/gis/db/models/sql/where.py  2009-04-14 
19:14:32 UTC (rev 10559)
@@ -76,17 +76,18 @@
 # the `get_geo_where_clause` to construct the appropriate
 # spatial SQL when `make_atom` is called.
 annotation = GeoAnnotation(field, value, where)
-return super(WhereNode, self).add((obj, lookup_type, annotation, 
params), connector)
+return super(WhereNode, self).add(((alias, col, field.db_type()), 
lookup_type, annotation, params), connector)
 
 def make_atom(self, child, qn):
-lvalue, lookup_type, value_annot, params = child
+obj, lookup_type, value_annot, params = child
 
 if isinstance(value_annot, GeoAnnotation):
 if lookup_type in SpatialBackend.gis_terms:
 # Getting the geographic where clause; substitution parameters
 # will be populated in the GeoFieldSQL object returned by the
 # GeometryField.
-gwc = get_geo_where_clause(lvalue.alias, lvalue.col, 
lookup_type, value_annot)
+alias, col, db_type = obj
+gwc = get_geo_where_clause(alias, col, lookup_type, 
value_annot)
 return gwc % value_annot.where, params
 else:
 raise TypeError('Invalid lookup type: %r' % lookup_type)

Modified: django/trunk/django/contrib/gis/tests/relatedapp/tests.py
===
--- django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2009-04-13 
15:16:17 UTC (rev 10558)
+++ django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2009-04-14 
19:14:32 UTC (rev 10559)
@@ -210,6 +210,18 @@
 self.assertEqual(val_dict['id'], c_id)
 self.assertEqual(val_dict['location__id'], l_id)
 
+def test10_combine(self):
+"Testing the combination of two GeoQuerySets.  See #10807."
+buf1 = City.objects.get(name='Aurora').location.point.buffer(0.1)
+buf2 = City.objects.get(name='Kecksburg').location.point.buffer(0.1)
+qs1 = City.objects.filter(location__point__within=buf1)
+qs2 = City.objects.filter(location__point__within=buf2)
+combined = qs1 | qs2
+names = [c.name for c in combined]
+self.assertEqual(2, len(names))
+self.failUnless('Aurora' in names)
+self.failUnless('Kecksburg' in names)
+
 # TODO: Related tests for KML, GML, and distance lookups.
 
 def suite():


--~--~-~--~~~---~--~~
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] #10784: list_editable will not work for the default ordering field.

[Django]

#10784: list_editable will not work for the default ordering field.
--+-
  Reporter:  andreplebl...@gmail.com  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  django.contrib.admin |   Version:  SVN   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by Alex):

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

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

Re: [Django] #10784: list_editable will not work for the default ordering field.

[Django]

#10784: list_editable will not work for the default ordering field.
--+-
  Reporter:  andreplebl...@gmail.com  | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.admin |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Old description:

> specifying a DateField as list_editable AND in the ordering of a model's
> Meta causes an error message stating 'Please correct the errors below'
> but doesn't list any errors.
>
> eg.
> {{{
> class TestModel(models.Model):
> name = models.CharField(max_length=40)
> birthdate = models.DateField(null=True, blank=True)
> class Meta:
> ordering = ('birthdate',)
>
> class TestModelAdmin(admin.ModelAdmin):
> list_display = ('name', 'birthdate')
> list_editable = ('birthdate', )
> }}}
> the birthdate field cannot actually be edited on the change list, it just
> shows that unhelpful message.  Not sure if this applies to all Field
> types or not, but definitely DateFields.

New description:

 specifying a DateField as list_editable AND in the ordering of a model's
 Meta causes an error message stating 'Please correct the errors below' but
 doesn't list any errors.

 eg.
 {{{
 #!python
 class TestModel(models.Model):
 name = models.CharField(max_length=40)
 birthdate = models.DateField(null=True, blank=True)
 class Meta:
 ordering = ('birthdate',)

 class TestModelAdmin(admin.ModelAdmin):
 list_display = ('name', 'birthdate')
 list_editable = ('birthdate', )
 }}}
 the birthdate field cannot actually be edited on the change list, it just
 shows that unhelpful message.  Not sure if this applies to all Field types
 or not, but definitely DateFields.

Comment (by Alex):

 I'm unable to reproduce with:
 {{{
 class Article(models.Model):
 title = models.CharField(max_length=100)
 pubdate = models.DateField()

 class Meta:
 ordering = ('pubdate',)

 class ArticleAdmin(admin.ModelAdmin):
 list_display = ('title', 'pubdate',)
 list_editable = ('pubdate',)
 }}}

 I'm going to close as worksforme now, if somehow can provide additional
 information to reproduce it or a testcase for Django's tests feel free to
 reopen.

-- 
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] #10776: there should be a link from slugfield description to prepopulated field description

[Django]

#10776: there should be a link from slugfield description to prepopulated field
description
+---
  Reporter:  ernop  | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

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

Re: [Django] #10761: ModelAdmin.queryset() is missing a mechanism for specifying different querysets for changelist and change object views

[Django]

#10761: ModelAdmin.queryset() is missing a mechanism for specifying different
querysets for changelist and change object views
---+
  Reporter:  mrts  | Owner:  nobody 
Status:  new   | Milestone:  1.2
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords:  efficient-admin
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * stage:  Unreviewed => Accepted

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

Re: [Django] #10741: Update GNU gettext on Windows note in i18n documentation

[Django]

#10741: Update GNU gettext on Windows note in i18n documentation
+---
  Reporter:  ramiro | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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
-~--~~~~--~~--~--~---

Re: [Django] #10737: Hard to find bug in code created by the tutorial

[Django]

#10737: Hard to find bug in code created by the tutorial
+---
  Reporter:  MateusJustino  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:  urlpatterns, debug
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 This reads like a support request, please use the django-users mailing
 list for 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] #10726: Admin url reversing docs are incomplete

[Django]

#10726: Admin url reversing docs are incomplete
+---
  Reporter:  Alex   | Owner:  Alex
Status:  new| Milestone:  1.1 
 Component:  Documentation  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * owner:  nobody => Alex
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Accepted

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

Re: [Django] #10712: ModelAdmin.queryset() is undocumented.

[Django]

#10712: ModelAdmin.queryset() is undocumented.
+---
  Reporter:  mrts   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution: |  Keywords:  efficient-admin
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  1  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Unreviewed => Accepted

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

[Django] #10814: management loaddata with verbosity > 0 fails silently under WSGI

[Django]

#10814: management loaddata with verbosity > 0 fails silently under WSGI
---+
 Reporter:  yourcelf   |   Owner:  nobody   
 
   Status:  new|   Milestone:   
 
Component:  Core framework | Version:  SVN  
 
 Keywords:  management loaddata verbosity stdout wsgi  |   Stage:  
Unreviewed
Has_patch:  0  |  
---+
 When using mod_wsgi and apache, a script which calls the following fails
 silently:

 {{{
 from django.core import management
 management.call_command("loaddata", "some_fixture")
 }}}

 Presumably, this has something to do with the fact that by default,
 "loaddata" prints status information to standard out, which is forbidden
 under WSGI.  The same command with "verbosity=0" succeeds.

 Rather than failing silently, the call with verbosty > 0 should either
 function properly or raise an exception when run under WSGI.

-- 
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] #10705: Admin_list.py - Items_for_result() hardcoding field type formating is ugly

[Django]

#10705: Admin_list.py - Items_for_result() hardcoding field type formating is 
ugly
---+
  Reporter:  Rupe  | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.0   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Marking as wontfix, the admin is separate from django.db.* quite
 intentionally, the idea is to sever that dependency as completely as
 possible, not increase 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] #10704: ifchanged-else documentation lost in r8506

[Django]

#10704: ifchanged-else documentation lost in r8506
+---
  Reporter:  Tarken | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

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

Re: [Django] #10061: incorrect logout link in admin

[Django]

#10061: incorrect logout link in admin
---+
  Reporter:  lashni| Owner:  Alex
Status:  reopened  | Milestone:  1.1 
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 Replying to [comment:21 dalore]:
 > Also with the latest trunk (with this patch removed), the admin urls are
 working again. So I think this patch might not be needed.

 This problem does still exist in Django trunk r10526.

 In case it's helpful to others: the simplest and least invasive temporary
 workaround is to just add this line in your urls.py:

 {{{
 admin.site.root_path = '/admin/'
 }}}

 If you run the admin at an alternate URL, just use the correct one here;
 if you run multiple admin instances, you can set the root_path for each
 one in the same way.

-- 
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] #10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with GeoQueryset

[Django]

#10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with
GeoQueryset
---+
  Reporter:  bretthoerner  | Owner:
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by bretthoerner):

 Well, it looks like the first occurrence of the relabel_aliases error
 (rather than Constraint is not iterable error in the above comment) is in
 [9888],

 {{{
 Traceback (most recent call last):
   File "../djtest/test.py", line 13, in 
 print qs1 | qs2
   File "/a/djtest/lib/python2.6/site-packages/django/db/models/query.py",
 line 256, in __or__
 combined.query.combine(other.query, sql.OR)
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 487, in combine
 w.relabel_aliases(change_map)
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/where.py", line 222, in relabel_aliases
 child[0].relabel_aliases(change_map)
 AttributeError: 'Constraint' object has no attribute 'relabel_aliases'
 }}}

-- 
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] #10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with GeoQueryset

[Django]

#10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with
GeoQueryset
---+
  Reporter:  bretthoerner  | Owner:
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by bretthoerner):

  * owner:  bretthoerner =>
  * status:  assigned => new

Comment:

 Whoops, un-assigning.

-- 
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] #10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with GeoQueryset

[Django]

#10807: 'Constraint' object has no attribute 'relabel_aliases' when using | with
GeoQueryset
---+
  Reporter:  bretthoerner  | Owner:  bretthoerner
Status:  assigned  | Milestone:  1.1 
 Component:  GIS   |   Version:  1.1-beta-1  
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by bretthoerner):

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

Comment:

 I used git-bisect that it broke on [9702],

 {{{
 Traceback (most recent call last):
   File "../djtest/test.py", line 13, in 
 print qs1 | qs2
   File "/a/djtest/lib/python2.6/site-packages/django/db/models/query.py",
 line 255, in __or__
 combined.query.combine(other.query, sql.OR)
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 373, in combine
 w.relabel_aliases(change_map)
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/where.py", line 211, in relabel_aliases
 elt = list(child[0])
 TypeError: 'Constraint' object is not iterable
 }}}

 [9702] were changes to catch up with [9700] on trunk, where the above test
 case gives the following,

 {{{
 Traceback (most recent call last):
   File "../djtest/test.py", line 11, in 
 qs1 = Place.objects.filter(name='A', location__distance_lte=(point,
 D(mi=5)))
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/manager.py", line 102, in filter
 return self.get_query_set().filter(*args, **kwargs)
   File "/a/djtest/lib/python2.6/site-packages/django/db/models/query.py",
 line 489, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "/a/djtest/lib/python2.6/site-packages/django/db/models/query.py",
 line 507, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 1241, in add_q
 can_reuse=used_aliases)
   File "/a/djtest/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 1184, in add_filter
 connector)
   File "/a/djtest/lib/python2.6/site-
 packages/django/contrib/gis/db/models/sql/where.py", line 32, in add
 alias, col, field, lookup_type, value = data
 ValueError: need more than 3 values to unpack
 }}}

-- 
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] #10799: List editable breaks with model inheritance and parent_link=True

[Django]

#10799: List editable breaks with model inheritance and parent_link=True
---+
  Reporter:  willhardy | Owner:  Alex   
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  list_editable 
parent_link inheritance
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by willhardy):

 I probably should have given my regression test a more descriptive title
 and a docstring, eg:
 {{{
 def test_inheritance_parent_link(self):
 " Ensure that the admin list_editable view works for models with
 parent_link. "
 }}}

-- 
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] #10664: non-serializing fixtures

[Django]

#10664: non-serializing fixtures
-+--
  Reporter:  lsaffre | Owner:  nobody  
Status:  new | Milestone:  
 Component:  django-admin.py |   Version:  1.0 
Resolution:  |  Keywords:  fixtures
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by kegan):

 +1 for this feature.

 Extremely useful when preparing fixtures for tests. During development,
 it's common to tweak your models. Non-serializing fixtures would allow
 preparation for test fixtures much easier, faster, and cleaner.

 The real use case for me (which I am facing now), is non-serializing
 fixtures would execute model custom save(), which ensure the model
 instance's states are intact. Otherwise, I would have to create a lot of
 corresponding "data", that would have been created in model custom save().

-- 
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] #9857: URLfield with verify_exists hangs if given an unresponsive URL

[Django]

#9857: URLfield with verify_exists hangs if given an unresponsive URL
---+
  Reporter:  aptiko| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Forms |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by trbs):

 As of Python2.6 urllib2 allows to specify a timeout argument to the
 urlopen() function.
 This should be the preferred way, since changes the timeout on the socket
 not the default for new sockets.

 The alternative patch uses this approach it checking for python versions
 and depending on the version use
 either urlopen(req, timeout=timeout) or a try-finally block to set and
 reset defaulttimeout.

 Currently the checks are all inside the URLField but it might be 'better'
 (in the sane that depending on a version check seems to be something one
 would like to avoid in principle) to check Python versions at import 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10675: escapejs doesn't handle U+2028 LINE SEPARATOR

[Django]

#10675: escapejs doesn't handle U+2028 LINE SEPARATOR
--+-
  Reporter:  olau | Owner:  rleland
Status:  closed   | Milestone:  1.1
 Component:  Template system  |   Version:  1.0
Resolution:  fixed|  Keywords: 
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by olau):

 Thanks to both of you!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #9857: URLfield with verify_exists hangs if given an unresponsive URL

[Django]

#9857: URLfield with verify_exists hangs if given an unresponsive URL
---+
  Reporter:  aptiko| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Forms |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by trbs):

 Couple of comments:

 Setting socket.setdefaulttimeout can very easily break or create problems
 with other running code depending on socket operations. Since the new
 timeout values applies to all newly created socket objects. If we must do
 it this way we should consider:

 {{{
 default_timeout = socket.getdefaulttimeout()
 socket.setdefaulttimeout(settings.SOCKET_DEFAULT_TIMEOUT)

 ... urllib2 code ...

 socket.setdefaulttimeout(default_timeout)
 }}}

 So not to disturb with other socket code. Still when another thread would
 use socket code and is executed between the first and second
 setdefaulttimeout() the problem still persists. This could be a potential
 problem specially for situations where Django runs in a threaded fcgi/wsgi
 enviroment ? I would imaging anybody running into a problem where suddenly
 his sockets would timeout to quickly would be rather dumbstruck and having
 a hard time figuring out why this happens. Specially since before the
 first verify_exists everything worked fine, while afterwards stuff started
 breaking. Something which could potentially happen in a development vs
 production kind of case, where development works fine but production
 magically breaks after a while because of the verify_exists check in a
 URLField which sets socket defaulttimeout to low. (or too high)

 Another point would be that IMO this kind of setting should be
 controllable from settings.py although most users would never ever see the
 attribute. Having this kind of hard coded (unchangeable) value seems
 wrong.

 Lastly.. when urlopen() times-out it raises URLError:  exception. So we should be able to catch that and provide a
 meaningful error message, which differs (slightly) from a normal broken-
 url and lets the user know the url timed out.

 Patch provided but still is not perfect (see threading comment).

-- 
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] #10813: Database errors in the shell should roll back the transaction

[Django]

#10813: Database errors in the shell should roll back the transaction
--+-
 Reporter:  Glenn |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 If an SQL statement fails in Postgresql, the connection refuses to run any
 further SQL commands until the transaction is rolled back.  In normal
 operation, this is fine; but in the shell, it's a constant aggrevation.

 This is related to #852, but that ticket was asking to automatically
 rollback inside the connection itself, which isn't good.  This ticket is
 only regarding the shell.  If I run a function that causes an SQL error,
 the shell's connection should not be left in an unusable state, forcing me
 to manually import db.transaction and roll back a transaction I never
 asked for.  The shell should catch DatabaseError and rollback before
 returning to the console.

 The attached patch implements this.  I've only tested with Postgresql.
 This does not affect IPython (which I know nothing about).

 Before:

 {{{
 >>> obj = User(name="Bill")
 >>> obj.save()
 ...
 IntegrityError: duplicate key value violates unique constraint
 "app_user_name_key"

 >>> obj.name = "Jim"
 >>> obj.save()
 ...
 InternalError: current transaction is aborted, commands ignored until end
 of transaction block
 }}}

 Now:

 {{{
 >>> obj = User(name="Bill")
 >>> obj.save()
 ...
 IntegrityError: duplicate key value violates unique constraint
 "app_user_name_key"

 >>> obj.name = "Jim"
 >>> obj.save()
 >>>
 }}}

-- 
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] #10812: Slight documentation inconsistency in querysets.txt

[Django]

#10812: Slight documentation inconsistency in querysets.txt
---+
 Reporter:  uzi|   Owner:  nobody
   Status:  new|   Milestone:  1.1   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Under http://docs.djangoproject.com/en/dev/ref/models/querysets/#id8 there
 is an example with


 {{{
 >>> q[0].entry__count
 }}}

 and below it the text

 {{{
 The Blog model doesn't define an entry_count attribute by itself ...
 }}}

 That one has one underscore and the other two may be inconsistent (it's
 subjective).  Just in case, here's a bug and a patch.

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