Re: [Django] #10160: F expression literals should use bind parameters

[Django]

#10160: F expression literals should use bind parameters
---+
  Reporter:  ikelly| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 Yeah that's defintely an improvement F('field') - 'string' shouldn't turn
 'string' into a fieldname automatically.

-- 
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] #10160: F expression literals should use bind parameters

[Django]

#10160: F expression literals should use bind parameters
---+
  Reporter:  ikelly| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 The first patch doesn't quite work. It successfully passes non-string
 types as bind parameters, but string values were still just getting
 processed by quote_name, and string values are the most dangerous.

 The new patch fixes this by removing the attempt to process the value with
 quote_name entirely. This introduces a minor backward incompatibility,
 since it's no longer possible to do things like
 `.filter(amount__lt=F('max_amount')-'surplus')` and have `'surplus'`
 automatically be included as a field name. But this can still be
 accomplished by using `F('surplus')` instead, which is better anyway since
 it's explicit.

-- 
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] #10142: Doctests failing on aggregation

[Django]

#10142: Doctests failing on aggregation
+---
  Reporter:  Vinay Sajip   | Owner:
 
Status:  reopened   | Milestone:  
post-1.0   
 Component:  ORM aggregation|   Version:  
SVN
Resolution: |  Keywords:  
doctest failure
 Stage:  Accepted   | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by mtredinnick):

 By the way, for comparison with our existing practices, I'll point to
 `django/db/backends/oracle/base.py` have a look at `regex_lookup_9()`
 (a.k.a "no regular expressions for ''you''") and `regex_lookup_10()`.
 That's actually a case of us being nice, since we could just continue on
 and error out later. But I think the same approach can be used in this
 case.

-- 
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] #10142: Doctests failing on aggregation

[Django]

#10142: Doctests failing on aggregation
+---
  Reporter:  Vinay Sajip   | Owner:
 
Status:  reopened   | Milestone:  
post-1.0   
 Component:  ORM aggregation|   Version:  
SVN
Resolution: |  Keywords:  
doctest failure
 Stage:  Accepted   | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by mtredinnick):

 This is fairly dangerous for users (cool bug, though!). It will appear to
 work and give wildly incorrect answers. When postgreSQL gets it wrong,
 they clearly don't stoop to half-measure. This isn't exactly a rounding
 error.

 Most of the database-specific problems we've got manifest themselves as
 fatal errors when you encounter them (all the SQLite ones do. The MySQL
 collation issue is the only trappy case that doesn't). This one is going
 to be much harder to detect.

 We might be best served by adding a "supports variance"
 `DatabaseOperations` check that returns True always, except for particular
 PostgreSQL versions. Then we can error out, fatally, if code encounters
 that. I'm really worried about quietly succeeding and returning the wrong
 answer and nobody until far too late (the numbers aren't so wrong that
 they'll look intuitively broken) . PostgreSQL 8.2 is hardly the most
 uncommon server on the planet.

-- 
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] #10142: Doctests failing on aggregation

[Django]

#10142: Doctests failing on aggregation
+---
  Reporter:  Vinay Sajip   | Owner:
 
Status:  reopened   | Milestone:  
post-1.0   
 Component:  ORM aggregation|   Version:  
SVN
Resolution: |  Keywords:  
doctest failure
 Stage:  Accepted   | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * status:  closed => reopened
  * resolution:  invalid =>
  * stage:  Unreviewed => Accepted

Comment:

 Based on Ian's link, this certainly appears to fall into the 'update your
 version of Postgres' basket. However, we should document the exact
 version(s) of Postgres that might be affected by this bug. We already
 document a number of known problems with SQLite and MySQL, so we shouldn't
 leave Postgres out of the fun :-)

 Looking at the Postgres release notes, it looks like this was
 [http://developer.postgresql.org/pgdocs/postgres/release-8-2.html
 introduced in 8.2] and
 [http://developer.postgresql.org/pgdocs/postgres/release-8-2-5.html fixed
 in 8.2.5]

 Vinay - can you confirm that this matches you Postgres installation (i.e.,
 you have an installed version somewhere between 8.2 and 8.2.4)?

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

[Django]

#10142: Doctests failing on aggregation
+---
  Reporter:  Vinay Sajip   | Owner:
 
Status:  closed | Milestone:  
post-1.0   
 Component:  ORM aggregation|   Version:  
SVN
Resolution:  invalid|  Keywords:  
doctest failure
 Stage:  Unreviewed | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by ikelly):

 Er, this was the link I intended to include:

 http://archives.postgresql.org/pgsql-bugs/2007-07/msg00046.php

-- 
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] #10142: Doctests failing on aggregation

[Django]

#10142: Doctests failing on aggregation
+---
  Reporter:  Vinay Sajip   | Owner:
 
Status:  closed | Milestone:  
post-1.0   
 Component:  ORM aggregation|   Version:  
SVN
Resolution:  invalid|  Keywords:  
doctest failure
 Stage:  Unreviewed | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by ikelly):

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

Comment:

 This appears to be an old postgresql bug where stddev and variance were
 computed incorrectly:

 http://archives.postgresql.org/pgsql-jdbc/2007-07/msg00033.php

 The bug does not occur with postgresql 8.2.11, so I surmise it was fixed
 some time before then.

-- 
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] #8087: Template tags 'ifin' and 'ifnotin' checking if element is present in sequence

[Django]

#8087: Template tags 'ifin' and 'ifnotin' checking if element is present in
sequence
-+--
  Reporter:  emes| Owner:  nobody   
 
Status:  new | Milestone:  post-1.0 
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:  templatetag, 
tag, sequence
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by Dagur):

 Why hasn't this been done in Django already. I mean, what are the
 arguments against 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
-~--~~~~--~~--~--~---

[Django] #10161: Fix F expressions with Oracle

[Django]

#10161: Fix F expressions with Oracle
--+-
 Reporter:  ikelly|   Owner:  ikelly
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The `%`, `&`, and `|` operators don't work.  See
 http://groups.google.com/group/django-
 developers/browse_thread/thread/4b6b987940ce16eb?hl=en

-- 
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] #10160: F expression literals should use bind parameters

[Django]

#10160: F expression literals should use bind parameters
---+
  Reporter:  ikelly| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ikelly):

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

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

[Django] #10160: F expression literals should use bind parameters

[Django]

#10160: F expression literals should use bind parameters
--+-
 Reporter:  ikelly|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 To prevent SQL injection attacks, Python values used within F()
 expressions should be processed as bind parameters rather than be inserted
 directly into the SQL.

-- 
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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+--
  Reporter:  jkocherhans | Owner:  adrian  
Status:  assigned| Milestone:  post-1.0
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by gsakkis):

 Updated Vinay's patch so that the admin views expose the app's
 verbose_name as app_label in the templates; also fixed a bug in
 `django/contrib/auth/management/__init__.py` that prevents
 `create_superuser` to be called in syncdb.

 Applies cleanly to r9498, the latest trunk revision before the the 1.0.2
 release. Hope some core-dev takes a look at it and gives feedback before
 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] #10159: Fix F() expressions to work on geographic fields.

[Django]

#10159: Fix F() expressions to work on geographic fields.
-+--
  Reporter:  jbronn  | Owner:  jbronn  
Status:  new | Milestone:  post-1.0
 Component:  GIS |   Version:  SVN 
Resolution:  |  Keywords:  gis expression where
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  1   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * needs_better_patch:  => 0
  * needs_tests:  => 1
  * needs_docs:  => 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
-~--~~~~--~~--~--~---

[Django] #10159: Fix F() expressions to work on geographic fields.

[Django]

#10159: Fix F() expressions to work on geographic fields.
--+-
 Reporter:  jbronn|   Owner:  jbronn
   Status:  new   |   Milestone:  post-1.0  
Component:  GIS   | Version:  SVN   
 Keywords:  gis expression where  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Currently, users will receive a `TypeError` when trying to use a `F()`
 expression on geographic field.  The attached patch is a preliminary fix
 and needs tests.

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

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

[Django]

#5897: Add Content-Length header in common middleware
---+
  Reporter:  Scott Barr   | Owner: 
 nobody   
Status:  new   | Milestone: 
  
 Component:  HTTP handling |   Version: 
 SVN  
Resolution:|  Keywords: 
 Content-Length middleware
 Stage:  Design decision needed| Has_patch: 
 1
Needs_docs:  0 |   Needs_tests: 
 0
Needs_better_patch:  0 |  
---+
Comment (by fumanchu):

 The advantage is following the HTTP spec, which mandates that messages
 either:

  1. be length 0 by design (e.g. HEAD)
  2. use "chunked" encoding
  3. provide Content-Length
  4. use the multipart/byteranges media type, or
  5. close the connection.

 Options 1, 2, and 4 are rare, so omitting C-L leaves us with (5) and
 therefore means conns can't ever use keepalive. I would say that any
 response with a buffered body, not just 200, should get a C-L response
 header.

 In addition, the len(str) function seems to be nearly O(1) up to about
 95MB:

 {{{
 #!python
 >>> for size in range(10):
 ... timeit.Timer("len(a)", "a = 'a' * %d" % (10 ** size)).timeit()
 ...
 0.090876075031882553
 0.092112894236557996
 0.091411897322145691
 0.096701326565247825
 0.095689815325690875
 0.098474945838088412
 0.09903919352878654
 0.097267250446634979
 0.09309835467915617
 0.4417090719630572
 >>> 10 ** 8
 1
 >>> _ / 1024
 97656
 >>> _ / 1024
 95
 }}}

-- 
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] #8765: mod_python handler requires explicit str() cast for HttpResponse(mimetype=...)

[Django]

#8765: mod_python handler requires explicit str() cast for
HttpResponse(mimetype=...)
+---
  Reporter:  semenov| Owner:  nobody
  
Status:  closed | Milestone:
  
 Component:  HTTP handling  |   Version:  SVN   
  
Resolution:  invalid|  Keywords:  mod_python content-type 
mimetype
 Stage:  Unreviewed | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by arien):

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

Comment:

 The [http://tools.ietf.org/html/rfc2616#section-14.17 syntax of the
 Content-Type header] is...
 {{{
   Content-Type   = "Content-Type" ":" media-type
 }}}
 ... where [http://tools.ietf.org/html/rfc2616#section-3.7 the syntax of
 media-type]  is...
 {{{
media-type = type "/" subtype *( ";" parameter )
type   = token
subtype= token
 }}}
 ... and [http://tools.ietf.org/html/rfc2616#section-2.2 token] and
 [http://tools.ietf.org/html/rfc2616#section-3.6 parameter] are sequences
 of characters from a subset of (7-bit) US-ASCII.

 Marking invalid.

-- 
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] #10158: error in forms docs

[Django]

#10158: error in forms docs
+---
  Reporter:  turadg | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ubernostrum):

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

Comment:

 `render_to_response` doesn't require a "request" parameter.

-- 
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] #6961: loaddata fails if models directory instead of models.py

[Django]

#6961: loaddata fails if models directory instead of models.py
--+-
  Reporter:  pmd  | Owner:  nobody  
Status:  new  | Milestone:  
 Component:  django-admin.py  |   Version:  SVN 
Resolution:   |  Keywords:  loaddata
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by mmalone):

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

Comment:

 Seems what we're really trying to do here is determine whether the models
 module (return by {{{get_apps()}}}) is a package (a directory with an
 {{{__init__.py}}} and submodules) or a normal module. According to
 [http://www.python.org/doc/essays/packages.html an essay] that was
 published when package support landed in Python, the only difference
 between a package and an ordinary module is that a package has a
 {{{__path__}}} attribute. Handily enough, the {{{__path__}}} attribute is
 an array that, by default, contains a single string pointing to the
 package directory, which is at the equivalent level in the file system
 directory hierarchy as {{{models.py}}}.

 I've attached a patch that checks the modules for the existence of a
 {{{__path__}}} attribute and handles them properly (and another patch
 containing some tests). I'm fairly confident this is the right way to do
 this, given the essay linked to above. I think this method may also be
 used to remove the Meta.app_label requirement for models submodules.

-- 
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] #8378: Generic views cache-like behavior

[Django]

#8378: Generic views cache-like behavior
+---
  Reporter:  ovidiup| Owner:  nobody
Status:  new| Milestone:  post-1.0  
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:  generic view cache
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by zbyte64):

 Couldn't we make the generic views check if the queryset parameter is
 callable, and if so, call it per request. So an example would be:

 url(r'^$', 'django.views.generic.list_detail.object_list',
 {'queryset':ClassifiedCategory.objects.all(),}, 'classifieds'),

 would then become:

 url(r'^$', 'django.views.generic.list_detail.object_list',
 {'queryset':ClassifiedCategory.objects.all,}, 'classifieds'),

 Furthermore, the queyset is not callable. Alternatively, the generic view
 could do a hasattr(queryset, '_clone') and call based off 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
-~--~~~~--~~--~--~---

[Django] #10158: error in forms docs

[Django]

#10158: error in forms docs
---+
 Reporter:  turadg |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 on this page,
 http://docs.djangoproject.com/en/dev/topics/forms/?from=olddocs

 there is a function shown,

 def contact(request):
 if request.method == 'POST': # If the form has been submitted...
 form = ContactForm(request.POST) # A form bound to the POST data
 if form.is_valid(): # All validation rules pass
 # Process the data in form.cleaned_data
 # ...
 return HttpResponseRedirect('/thanks/') # Redirect after POST
 else:
 form = ContactForm() # An unbound form

 return render_to_response('contact.html', {
 'form': form,
 })


 the render_to_response method is missing the 'request' parameter.


 also, I implore you to allow users to comment like the PHP docs do.

-- 
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] #8159: Attempting to delete your own user account in Django admin view is not handled properly

[Django]

#8159: Attempting to delete your own user account in Django admin view is not
handled properly
---+
  Reporter:  eri...@calytrix.com   | Owner:  graham_king 
Status:  assigned  | Milestone:  post-1.0
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  admin delete
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by graham_king):

  * needs_better_patch:  1 => 0

Comment:

 Yes, that was the problem. I have added a test for that case.

 I've updated the patch to take a different route. It catches the
 IntegrityError. If the logged in user is gone, it ignores the exception,
 if not it raises it.

 The crux of the problem is that the same user is in memory twice - once as
 the logged in user and once as the deleted user. The id of the deleted
 user gets correctly null-ed, but not the id of the logged in user. The
 single instance proposal would fix this:
 http://code.djangoproject.com/wiki/DjangoSpecifications/Core/SingleInstance

 In the meantime this patch adds a helpful warning and prevents things
 blowing 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7980: I18N needs improvements

[Django]

#7980: I18N needs improvements
---+
  Reporter:  garcia_marc   | Owner:  garcia_marc
  
Status:  new   | Milestone:  post-1.0   
  
 Component:  Internationalization  |   Version:  SVN
  
Resolution:|  Keywords:  date decimal 
calendar i18n-rf
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  1 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Changes (by alexkon):

 * cc: alex...@gmail.com (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
-~--~~~~--~~--~--~---

[Django] #10157: Assignment to a reverse OneToOne overwrites related object's PK

[Django]

#10157: Assignment to a reverse OneToOne overwrites related object's PK
--+-
 Reporter:  Anossov   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  onetoone  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 example models:
 {{{
 class User(models.Model):
 name = models.CharField(max_length=10)
 def __unicode__(self):
 return '' % self.name

 class UserProfile(models.Model):
 user = models.OneToOneField(User, related_name='profile', null=True)
 }}}

 [[BR]]

 When I try to assign a !UserProfile instance to a User instance's
 “profile” attribute, !UserProfile's PK !AutoField gets overwritten with
 the User instance:
 {{{
 >>> u = User(name='test')
 >>> p = UserProfile()
 >>> print p.id, p.user
 None None
 >>> u.profile = p
 >>> print p.id, p.user
  
 # Expected: None 
 }}}

-- 
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] #10154: allow the combination of an F expression with a timedelta

[Django]

#10154: allow the combination of an F expression with a timedelta
---+
  Reporter:  Koen Biermans   | 
Owner:  nobody 
Status:  new   | 
Milestone: 
 Component:  Database layer (models, ORM)  |   
Version:  SVN
Resolution:|  
Keywords:  expressions
 Stage:  Unreviewed| 
Has_patch:  1  
Needs_docs:  0 |   
Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Reflejo):

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

Comment:

 I'm mostly -1 regarding how Leaf.evaluate() is implemented. Maybe is more
 simple if timedelta is converted to seconds (delta.seconds + delta.day *
 86400), so you don't need to do that "mods" things :-).

 This way you can move representations to each backend.

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

[Changeset] r9800 - django/trunk/tests/regressiontests/aggregation_regress

[noreply]

Author: ikelly
Date: 2009-01-30 14:15:41 -0600 (Fri, 30 Jan 2009)
New Revision: 9800

Modified:
   django/trunk/tests/regressiontests/aggregation_regress/models.py
Log:
Fixed some tests that relied on an arbitrary ordering of rows.

Modified: django/trunk/tests/regressiontests/aggregation_regress/models.py
===
--- django/trunk/tests/regressiontests/aggregation_regress/models.py
2009-01-30 20:02:42 UTC (rev 9799)
+++ django/trunk/tests/regressiontests/aggregation_regress/models.py
2009-01-30 20:15:41 UTC (rev 9800)
@@ -166,18 +166,18 @@
 
 # Aggregates can be used with F() expressions
 # ... where the F() is pushed into the HAVING clause
->>> 
Publisher.objects.annotate(num_books=Count('book')).filter(num_books__lt=F('num_awards')/2).values('name','num_books','num_awards')
-[{'num_books': 2, 'name': u'Prentice Hall', 'num_awards': 7}, {'num_books': 1, 
'name': u'Morgan Kaufmann', 'num_awards': 9}]
+>>> 
Publisher.objects.annotate(num_books=Count('book')).filter(num_books__lt=F('num_awards')/2).order_by('name').values('name','num_books','num_awards')
+[{'num_books': 1, 'name': u'Morgan Kaufmann', 'num_awards': 9}, {'num_books': 
2, 'name': u'Prentice Hall', 'num_awards': 7}]
 
->>> 
Publisher.objects.annotate(num_books=Count('book')).exclude(num_books__lt=F('num_awards')/2).values('name','num_books','num_awards')
-[{'num_books': 2, 'name': u'Apress', 'num_awards': 3}, {'num_books': 1, 
'name': u'Sams', 'num_awards': 1}, {'num_books': 0, 'name': u"Jonno's House of 
Books", 'num_awards': 0}]
+>>> 
Publisher.objects.annotate(num_books=Count('book')).exclude(num_books__lt=F('num_awards')/2).order_by('name').values('name','num_books','num_awards')
+[{'num_books': 2, 'name': u'Apress', 'num_awards': 3}, {'num_books': 0, 
'name': u"Jonno's House of Books", 'num_awards': 0}, {'num_books': 1, 'name': 
u'Sams', 'num_awards': 1}]
 
 # ... and where the F() references an aggregate
->>> 
Publisher.objects.annotate(num_books=Count('book')).filter(num_awards__gt=2*F('num_books')).values('name','num_books','num_awards')
-[{'num_books': 2, 'name': u'Prentice Hall', 'num_awards': 7}, {'num_books': 1, 
'name': u'Morgan Kaufmann', 'num_awards': 9}]
+>>> 
Publisher.objects.annotate(num_books=Count('book')).filter(num_awards__gt=2*F('num_books')).order_by('name').values('name','num_books','num_awards')
+[{'num_books': 1, 'name': u'Morgan Kaufmann', 'num_awards': 9}, {'num_books': 
2, 'name': u'Prentice Hall', 'num_awards': 7}]
 
->>> 
Publisher.objects.annotate(num_books=Count('book')).exclude(num_books__lt=F('num_awards')/2).values('name','num_books','num_awards')
-[{'num_books': 2, 'name': u'Apress', 'num_awards': 3}, {'num_books': 1, 
'name': u'Sams', 'num_awards': 1}, {'num_books': 0, 'name': u"Jonno's House of 
Books", 'num_awards': 0}]
+>>> 
Publisher.objects.annotate(num_books=Count('book')).exclude(num_books__lt=F('num_awards')/2).order_by('name').values('name','num_books','num_awards')
+[{'num_books': 2, 'name': u'Apress', 'num_awards': 3}, {'num_books': 0, 
'name': u"Jonno's House of Books", 'num_awards': 0}, {'num_books': 1, 'name': 
u'Sams', 'num_awards': 1}]
 
 # Regression for #10089: Check handling of empty result sets with aggregates
 >>> Book.objects.filter(id__in=[]).count()


--~--~-~--~~~---~--~~
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] r9799 - django/trunk/tests/regressiontests/expressions_regress

[noreply]

Author: ikelly
Date: 2009-01-30 14:02:42 -0600 (Fri, 30 Jan 2009)
New Revision: 9799

Modified:
   django/trunk/tests/regressiontests/expressions_regress/models.py
Log:
Fixed some column names in the tests that were breaking the test suite on 
Oracle.

Modified: django/trunk/tests/regressiontests/expressions_regress/models.py
===
--- django/trunk/tests/regressiontests/expressions_regress/models.py
2009-01-29 23:40:57 UTC (rev 9798)
+++ django/trunk/tests/regressiontests/expressions_regress/models.py
2009-01-30 20:02:42 UTC (rev 9799)
@@ -9,8 +9,8 @@
 #
 
 class Number(models.Model):
-integer = models.IntegerField()
-float = models.FloatField(null=True)
+integer = models.IntegerField(db_column='the_integer')
+float = models.FloatField(null=True, db_column='the_float')
 
 def __unicode__(self):
 return u'%i, %.3f' % (self.integer, self.float)


--~--~-~--~~~---~--~~
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] #8734: Slightly complex built-in Field classes not documented.

[Django]

#8734: Slightly complex built-in Field classes not documented.
+---
  Reporter:  dlparker   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by arien):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * summary:  Forms documentation refers to unit tests but no longer has
  link to them => Slightly complex built-in Field
  classes not documented.
  * version:  1.0-beta-1 => SVN
  * needs_docs:  => 1
  * stage:  Unreviewed => Accepted

Comment:

 The unit tests haven't been mentioned in
 [http://docs.djangoproject.com/en/dev/ref/forms/fields/#slightly-complex-
 built-in-field-classes the form field docs] since the docs refactor landed
 in [8506].

 However, the real issue is that these classes lack documentation, so I'll
 leave this ticket open and change the summary to reflect that.  (There
 doesn't seem to be a ticket for this issue yet.)

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

[Django] #10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice

[Django]

#10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice
---+
 Reporter:  Alex   |   Owner:  Alex  
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Which is hugely inefficient, selecting 20 items already means you're going
 outside the reasonable limits for SQL queries.

-- 
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] #10155: problems running syncdb with PostgreSQL 8.4

[Django]

#10155: problems running syncdb with PostgreSQL 8.4
---+
  Reporter:  ed.j.valent...@gmail.com  | Owner:  nobody 
   
Status:  closed| Milestone:  post-1.0   
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:  invalid   |  Keywords:  PostgreSQL 
8.4
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 This question would be better asked on django-users.  If responses reveal
 there is a bug in Django with respect to running on a particular level of
 PostgreSQL, then a ticket would be appropriate. Until then you will get
 more people viewing your question and possibly able to provide responses
 than you will from a ticket.  This also may be a dup of #8737, but it's
 impossible to say for sure without more information.  So when you post on
 django-users please do include specifics of the error (e.g. cut and paste
 the output of the command that fails), not just a vague "looks like it is
 having a problem with the 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #10155: problems running syncdb with PostgreSQL 8.4

[Django]

#10155: problems running syncdb with PostgreSQL 8.4
--+-
 Reporter:  ed.j.valent...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  PostgreSQL 8.4|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have one system with Fedora and PostgreSQL 8.3 and Tutorial works fine.
 I installed a CentOS EL5 server, it has PostgreSQL 8.4, and can not run
 the Tutorial. It fails on the 'python manage.py syncdb'. It looks like it
 is having a problem with the version or the new permissions.

 Do I need to use PostgreSQL 8.3 with the Django Framework?

 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] #6362: Remove blank spaces with strip when validating the data

[Django]

#6362: Remove blank spaces with strip when validating the data
-+--
  Reporter:  marinho | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  SVN  
Resolution:  |  Keywords:  blank space strip
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by marinho):

 @julianb

 When I said "most of cases" I wasn't meaning "most of us in this
 discussion", but '''"most of projects made using Django"'''. And for
 exceptional cases, there would be an attribute to set 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] #10015: contrib.comments inline on Postgres 8.3 fails to cast integer to text

[Django]

#10015: contrib.comments inline on Postgres 8.3 fails to cast integer to text
---+
  Reporter:  carljm| Owner:  carljm  
Status:  assigned  | Milestone:  
 Component:  Contrib apps  |   Version:  1.0 
Resolution:|  Keywords:  comments, postgresql, pk
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: m...@mylesbraithwaite.com (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
-~--~~~~--~~--~--~---

[Django] #10154: allow the combination of an F expression with a timedelta

[Django]

#10154: allow the combination of an F expression with a timedelta
--+-
 Reporter:  Koen Biermans   |   Owner:  
nobody
   Status:  new   |   Milestone:

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

 Keywords:  expressions   |   Stage:  
Unreviewed
Has_patch:  1 |  
--+-
 The proposal is to allow combining a F expression with a timedelta.

 eg:

 {{{
 >>> longevents =
 Event.objects.filter(enddate__gt=F('startdate')+datetime.timedelta(days=5))
 }}}

 would return the events longer than 5 days.

 I am attaching a first patch, which obviously needs refining.

-- 
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] #6407: ModelChoiceField with widget=HiddenInput doesn't behave as expected

[Django]

#6407: ModelChoiceField with widget=HiddenInput doesn't behave as expected
--+-
  Reporter:  Andy McCurdy   | Owner:  nobody  

Status:  closed   | Milestone:  

 Component:  Forms|   Version:  SVN 

Resolution:  worksforme   |  Keywords:  
ModelChoiceField HiddenInput
 Stage:  Unreviewed   | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

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

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

Comment:

 I'm unable to reproduce this.

 I don't see how `MyForm` would ever validate: for the value of ``user`` to
 be a valid choice it has to be in the ``EmptyQuerySet`` produced by
 ``User.objects.none()``, which by definition is empty.

 Changing ``MyForm`` so that the ``user`` field gets passed e.g.
 ``queryset=User.objects.all()``, the form validates just fine:

 {{{
 >>> from django.contrib.auth.models import User
 >>> from t6407.forms import MyForm
 >>>
 >>> u = User.objects.get(pk=1)
 >>> f = MyForm(initial={'user': u.pk})
 >>> print f
 Body:
 >>>
 >>> f = MyForm({'body': '...', 'user': '1'})
 >>> f.is_valid()
 True
 >>> f.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] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
---+
  Reporter:  russellm  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql 
innodb myisam reference fixture
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 You are right, it's not a complete solution.  Turning foreign key checks
 off and then back on lets you introduce integrity errors in the meantime.
 A complete solution would incorporate something like that referenced
 stored procedure to check what-all had been done during the "defer check"
 block and raise an error if there was a constraint violation found.
 However, I don't have a whole lot of interest in implementing that myself.
 It'd be nice...but if the database itself can't be bothered to do this,
 I'm having a hard time working up motivation to devote time to it.
 However, if we do provide these routines, we do start to have a hook in
 place for saying "here's where the logic needs to go if you want to make
 this safer on InnoDB" (or any other DB that does not do deferred
 constraint checking).

 I did not realize it was a concern that it was very easy to generate
 invalid fixtures, and thus not safe for loaddata to simply use this by
 default.  I can look at changing that, maybe via a flag to loaddata?  I
 think that was how I originally thought I would approach it but then one
 of the other patches just put it in loaddata by default, so I did the
 same.

 On the deletes, I didn't know how safe it would be to put these inside the
 innards of the delete processing, so I just put them in the tests.  Since
 the tests pass on other, more advanced w.r.t. constraint checking, DBs, I
 thought it was safe to bracket the calls in the tests, but didn't know if
 it would be safe in general.  Since we implement cascading delete manually
 I suppose it should be safe...but didn't quite feel comfortable making
 that leap myself.

 I also did first approach this by just fixing up the new fixtures to not
 trip this bug.  That's do-able via re-ordering and removing forward
 references in the !ManyToManys...but it's error prone, can't be done for
 all (e.g. circular) fixtures, has to be re-done if the fixtures are ever
 re-generated programmatically, or whenever new ones are introduced...as I
 thought about it more and more the list of downsides to that approach got
 so long I thought it might be worthwhile trying to do something to address
 the underlying problem, even if at this point it isn't a complete answer.

 (I did also briefly consider adding checks for the DB in use (there's
 already at least one such check) to the tests and issuing the SET
 FOREIGN_KEY_CHECKS=0/1 there when necessary, but that is really ugly and
 does nothing to help for similar situations on other DBs.  As it is it
 isn't clear to me if this approach really helps at all for MS SQL Server,
 since it apparently wants table names on which to turn off constraint
 checking, but maybe someone who knows more (Ramiro?) on that topic can
 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
-~--~~~~--~~--~--~---

Re: [Django] #7048: Support clearing FileFields in the admin if blank=True

[Django]

#7048: Support clearing FileFields in the admin if blank=True
---+
  Reporter:  jarrow| Owner:  brosner 
Status:  assigned  | Milestone:  post-1.0
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: flo...@gmail.com (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] #6362: Remove blank spaces with strip when validating the data

[Django]

#6362: Remove blank spaces with strip when validating the data
-+--
  Reporter:  marinho | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Forms   |   Version:  SVN  
Resolution:  |  Keywords:  blank space strip
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by julianb):

 Replying to [comment:24 marinho]:
 > I'm sure most of cases people don't want keep blank spaces at left or
 right of cleaned strings.

 That might be, but as everyone here was told "Even if 100 people [think
 so], that's less than .1% of the userbase, so is entirely non-
 representative. The resolution will be on the merits, not some straw
 count."

 I'm wondering when that is happening.

-- 
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] #3615: Can't define forward references in fixtures using MySQL with InnoDB

[Django]

#3615: Can't define forward references in fixtures using MySQL with InnoDB
---+
  Reporter:  russellm  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  mysql 
innodb myisam reference fixture
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Karen -  I'm not convinced about this implementation. I looked at using
 SET FOREIGN KEY CHECKS=0 back when I opened this ticket, but decided that
 it wasn't a complete solution.

 As I recall (and I haven't looked into this for a while, so feel free to
 correct me), the reason I walked away from the problem was that using SET
 FOREIGN_KEY_CHECKS=0 will make the failures in the Django test system go
 away, but at the cost of allowing users to completely screw up their
 database. If your try to load a badly formed fixture -- for example, a
 fixture that contains a foreign key reference to a non-existent object --
 and you have foreign key checks turned off, the database doesn't re-
 validate when you turn foreign key checks back on. This means you have an
 InnoDB table that doesn't have referential integrity, which kind of
 defeats one of the reasons for using InnoDB in the first place. Given the
 ease with which broken fixtures can be produced, if we're going to turn
 this flag on and off automatically, I'd rather see a method that
 guaranteed actual referential integrity.

 My other comment is whether the calls to defer constraint checks that are
 required around calls to delete() should be a manual requirement of the
 user (as demonstrated by the test case), or if we should include them as
 top and tail calls in Django's delete implementation. Ideally, it would be
 nice for InnoDB users to not have to care about the requirements of their
 backend of choice. My only hesitation to suggesting this is the potential
 for an edge case that requires two (or more) successive calls to delete to
 completely purge an object network. I can't think of an obvious example
 that wouldn't be cleaned up by Django's normal dependency following delete
 logic, but I can't help but think that there might be one.

 Of course, the alternative approach to this entire problem is to openly
 state that InnoDB's constraint handling is broken, provide the
 (potentially dangerous) constraint checking calls as part of MySQL's
 operations backend, but make use of those calls _completely_ manual.
 Rather than embedding the calls into loaddata, we manually make the calls
 in Django's test framework as appropriate, and modify the documentation to
 tell InnoDB users that they may need to do the same in their code. It
 would be a big hairy wart on the API, but it would allow us to avoid a
 class of quite annoying test failures, and provides a solution for InnoDB
 users where no solution currently exists.

 As for the aggregation test failures - regardless of the design outcome
 for this ticket, we may be able to resolve the aggregation test failures
 by simply reordering the test fixture. There's nothing in the test fixture
 that requires the ordering presented - if we move the list of Authors to
 higher in the fixture, most of the serialization problems should go away.
 The only potential complication is the list of friends of each author - I
 haven't dug into detail to see if there are any circular references, but
 even if there are, I don't believe that they are essential for testing
 aggregation - we can easily change the test case to remove the circular
 dependencies, making the fixture InnoDB friendly.

-- 
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] #10148: get_or_create function documentation is not clear enough

[Django]

#10148: get_or_create function documentation is not clear enough
+---
  Reporter:  batiste| Owner:  nobody
  
Status:  closed | Milestone:
  
 Component:  Documentation  |   Version:  1.0   
  
Resolution:  invalid|  Keywords:  get_or_create, 
documentation
 Stage:  Unreviewed | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by arien):

 batiste, you might want to track #3182, which proposes adding an
 ``update_or_create`` to ``QuerySet`` objects.

-- 
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] #10099: MySQL 5.0 does not support LIMIT in subqueries

[Django]

#10099: MySQL 5.0 does not support LIMIT in subqueries
---+
  Reporter:  Anossov   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by lamby):

 Updated patch to fix issue when the evaluated was empty which was
 resulting in invalid SQL being generated ("WHERE foo_id IN ()"). This
 patch getting uglier and uglier. :(

-- 
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] #10153: 'gte' missing in get_db_prep_lookup lookup

[Django]

#10153: 'gte'  missing in  get_db_prep_lookup lookup
---+
 Reporter:  gatwanagu  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords:  queryset field lookup  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When using a field lookup
 {{{
 (unit__gte=3)
 }}}
  there is an error "Related Field has invalid lookup: ..." raised, when
 using the field lookup
 {{{
 (unit__gt=3)
 }}}
  it works fine.

 Reason is that in db/models/fields/related.py in the function
 get_db_prep_lookup the lookup_type is cross checked against a list, and in
 this list 'gte' is missing.

 Inserting 'gte' (and 'lte' to keep it synced) fixes the problem. There is
 a FIXME about this checking.

 I don't understand what is the big difference in handling 'gt' to 'gte'
 and why 'gte' and 'lte' can't be inserted

 Thanks

 Günter

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