Re: [Django] #12427: cmemcache has been retired / add support for cmemcached

[Django]

#12427: cmemcache has been retired / add support for cmemcached
-+--
  Reporter:  UloPe   | Owner:  otherjacob
Status:  assigned| Milestone:
 Component:  Cache system|   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by otherjacob):

  * 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-upda...@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] r12745 - django/trunk/tests/regressiontests/model_fields

[noreply]

Author: ubernostrum
Date: 2010-03-10 01:42:25 -0600 (Wed, 10 Mar 2010)
New Revision: 12745

Modified:
   django/trunk/tests/regressiontests/model_fields/models.py
   django/trunk/tests/regressiontests/model_fields/tests.py
Log:
Tests for [12744], which were accidentally left out of the commit. Refs #13071.

Modified: django/trunk/tests/regressiontests/model_fields/models.py
===
--- django/trunk/tests/regressiontests/model_fields/models.py   2010-03-10 
07:41:37 UTC (rev 12744)
+++ django/trunk/tests/regressiontests/model_fields/models.py   2010-03-10 
07:42:25 UTC (rev 12745)
@@ -63,7 +63,11 @@
 class Post(models.Model):
 title = models.CharField(max_length=100)
 body = models.TextField()
-
+
+class NullBooleanModel(models.Model):
+nbfield = models.NullBooleanField()
+
+
 ###
 # ImageField
 

Modified: django/trunk/tests/regressiontests/model_fields/tests.py
===
--- django/trunk/tests/regressiontests/model_fields/tests.py2010-03-10 
07:41:37 UTC (rev 12744)
+++ django/trunk/tests/regressiontests/model_fields/tests.py2010-03-10 
07:42:25 UTC (rev 12745)
@@ -6,7 +6,7 @@
 from django.db import models
 from django.core.exceptions import ValidationError
 
-from models import Foo, Bar, Whiz, BigD, BigS, Image, BigInt, Post
+from models import Foo, Bar, Whiz, BigD, BigS, Image, BigInt, Post, 
NullBooleanModel
 
 try:
 from decimal import Decimal
@@ -40,6 +40,18 @@
 form_field = model_field.formfield(show_hidden_initial=False)
 self.assertFalse(form_field.show_hidden_initial)
 
+def test_nullbooleanfield_blank(self):
+"""
+Regression test for #13071: NullBooleanField should not throw
+a validation error when given a value of None.
+
+"""
+nullboolean = NullBooleanModel(nbfield=None)
+try:
+nullboolean.full_clean()
+except ValidationError, e:
+self.fail("NullBooleanField failed validation with value of None: 
%s" % e.messages)
+
 class DecimalFieldTests(django.test.TestCase):
 def test_to_python(self):
 f = models.DecimalField(max_digits=4, decimal_places=2)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r12744 - django/trunk/django/db/models/fields

[noreply]

Author: ubernostrum
Date: 2010-03-10 01:41:37 -0600 (Wed, 10 Mar 2010)
New Revision: 12744

Modified:
   django/trunk/django/db/models/fields/__init__.py
Log:
Forced blank=True for NullBooleanField to allow it to pass model validation 
with a value of None. Refs #13071.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2010-03-10 03:41:41 UTC 
(rev 12743)
+++ django/trunk/django/db/models/fields/__init__.py2010-03-10 07:41:37 UTC 
(rev 12744)
@@ -935,6 +935,7 @@
 
 def __init__(self, *args, **kwargs):
 kwargs['null'] = True
+kwargs['blank'] = True
 Field.__init__(self, *args, **kwargs)
 
 def get_internal_type(self):

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13074: Typo in US localflavor docs: "Format of XXX-XX-XXXX"

[Django]

#13074: Typo in US localflavor docs: "Format of XXX-XX-"
+---
  Reporter:  mattmcc| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

-- 
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-upda...@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] #13074: Typo in US localflavor docs: "Format of XXX-XX-XXXX"

[Django]

#13074: Typo in US localflavor docs: "Format of XXX-XX-"
---+
 Reporter:  mattmcc|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Should be XXX-XXX-.

-- 
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-upda...@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] #13073: Duplicate rows when checking ID

[Django]

#13073: Duplicate rows when checking ID
---+
  Reporter:  jnadro52  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Closing worksforme. I can't reproduce your problem. If what you are
 describing were happening as you describe.

 A minimal example (that is - actual models, sample data and queries) that
 demonstrates the problem is essential if you want to report a problem like
 this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13070: Wrong exception on django.contrib.gis from SVN

[Django]

#13070: Wrong exception on django.contrib.gis from SVN
+---
  Reporter:  Guilherme Gondim (semente)   |   
  Owner:  nobody   
Status:  closed | 
Milestone:  1.2  
 Component:  GIS|   
Version:  SVN  
Resolution:  invalid|  
Keywords:  geodjango
 Stage:  Unreviewed | 
Has_patch:  0
Needs_docs:  0  |   
Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Closing invalid. I don't deny there's a problem, but a stack trace and the
 comment "can't use gis" doesn't help us reproduce it. Reopen if you care
 to provide *specific* details on how to reproduce the problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13065: Brazilian Portuguese locale updated

[Django]

#13065: Brazilian Portuguese locale updated
+---
  Reporter:  Guilherme Gondim (semente)   |   
  Owner:  nobody
Status:  new| 
Milestone:  1.2   
 Component:  Translations   |   
Version:  SVN   
Resolution: |  
Keywords:  pt_BR 
 Stage:  Accepted   | 
Has_patch:  1 
Needs_docs:  0  |   
Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * 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-upda...@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] #13067: make bulk-deletion lots faster

[Django]

#13067: make bulk-deletion lots faster
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * 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-upda...@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] #13071: NullBooleanField save error in Admin?

[Django]

#13071: NullBooleanField save error in Admin?
---+
  Reporter:  Ed Hagen  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  Contrib apps  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * 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-upda...@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] #13073: Duplicate rows when checking ID

[Django]

#13073: Duplicate rows when checking ID
--+-
 Reporter:  jnadro52  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hello:

 I hope that this is a legitimate bug and I'm not wasting your time with
 something that is a slight misunderstanding of how the Django database
 layer works.  Here we go...

 I have two tables... a table that holds football matchups (texans vs.
 giants, for example) and a table that caches the statistics for the game.
 The table that caches the statistics would have a row per team, so this is
 what the data would look like:


 {{{
 ID   team   opponent  matchup_id
 1texans giants1
 2giants texans1
 }}}


 So now I want to retrieve these two rows by matchup ID.  Lets say the
 model names are "matchup" and "cache".  So, I attempted to go retrieve
 them like so:


 {{{
 caches = cache.objects.filter(matchup=1)
 }}}


 When I do so, I do get two objects returned, but they are both the same
 cache row that is returned.  So I would get a QuerySet containing two
 objects, both of which would have the same primary key.

 What really confused me is that if I added a .distinct() method call to
 the end of that call, I would get the expected results.  If it is the case
 where there is a join occurring I would understand getting duplicates,
 even though I would think there should be no join in this call, since i am
 just checking a foreign key.  The kicker is that I always get row id 2 and
 never row id 1 when I make this call without the distinct call as well.
 If this were a cross-join, I should get multiple duplicates of all rows
 that meet the criteria, but I do not.

 I hope I explained this well enough, please feel free to contact me at my
 given email if you have any questions.

-- 
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-upda...@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] #13072: A few additional small reST fixes

[Django]

#13072: A  few additional small reST fixes
+---
  Reporter:  ramiro | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

-- 
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-upda...@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] #13066: cache.get and cache.set should have consistent key rules across different backends

[Django]

#13066: cache.get and cache.set should have consistent key rules across 
different
backends
-+--
  Reporter:  rbanffy | Owner:  nobody
Status:  new | Milestone:
 Component:  Cache system|   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by ubernostrum):

  * stage:  Accepted => Design decision needed
  * milestone:  1.2 =>

Comment:

 This isn't anywhere near important enough to be on the 1.2 milestone, and
 given the history of proposals related to this (see #6447 and #3241 in
 particular), probably needs a decision from the committers before being
 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-upda...@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] #9741: generic relations: reverse chain of references not followed fully on delete

[Django]

#9741: generic relations: reverse chain of references not followed fully on 
delete
---+
  Reporter:  wiswaud   | Owner:  aljosa 
  
Status:  new   | Milestone:  1.2
  
 Component:  Contrib apps  |   Version:  1.0
  
Resolution:|  Keywords:  genericrelation 
genericforeignkey
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mwdiers):

  * summary:  generic relations: reverse chain of references not followed
  fully yon delete => generic relations: reverse
  chain of references not followed fully on
  delete

-- 
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-upda...@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] #13072: A few additional small reST fixes

[Django]

#13072: A  few additional small reST fixes
---+
 Reporter:  ramiro |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 See attached 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-upda...@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] #13068: The "Add another [inline object]" javascript doesn't respect prepopulated_fields settings

[Django]

#13068: The "Add another [inline object]" javascript doesn't respect
prepopulated_fields settings
---+
  Reporter:  hejsan| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * version:  1.2-beta => SVN
  * milestone:  => 1.2
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 Confirmed the prepopulated_fields issue.

 On Firefox 3.5.8 I don't see any problem with the alternating row colors;
 in any case, if that actually is a problem in some browsers, it should get
 its own separate Trac issue.

-- 
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-upda...@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] #9982: Inconsistent behavior on model save depending on whether OneToOneField is a primary key

[Django]

#9982: Inconsistent behavior on model save depending on whether OneToOneField 
is a
primary key
---+
  Reporter:  s...@frontsquare.com  | Owner: 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  1.0
 
Resolution:|  Keywords:  
OneToOneField primary_key IntegrityError
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  mtredinnick =>
  * status:  assigned => new
  * milestone:  1.2 =>

Comment:

 Moving off the 1.2 milestone. As noted in the first comment, this should
 be raising an error in the case that appears to work, in the best case. So
 it's not a case of something not working that should.

-- 
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-upda...@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] #13066: cache.get and cache.set should have consistent key rules across different backends

[Django]

#13066: cache.get and cache.set should have consistent key rules across 
different
backends
---+
  Reporter:  rbanffy   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Cache system  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * version:  1.2-beta => SVN
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I've also been bitten by this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r12743 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2010-03-09 21:41:41 -0600 (Tue, 09 Mar 2010)
New Revision: 12743

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #11711 -- clarified that ValuesQuerySets are not lists per se.

It rarely hurts to think of the returned result from a values() or
values_list() call as a list, but it's really an iterable and sometimes
the difference matters.

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2010-03-10 03:12:48 UTC (rev 
12742)
+++ django/trunk/docs/ref/models/querysets.txt  2010-03-10 03:41:41 UTC (rev 
12743)
@@ -361,8 +361,8 @@
 ``values(*fields)``
 ~~~
 
-Returns a ``ValuesQuerySet`` -- a ``QuerySet`` that evaluates to a list of
-dictionaries instead of model-instance objects.
+Returns a ``ValuesQuerySet`` -- a ``QuerySet`` that returns dictionaries when
+used as an iterable, rather than model-instance objects.
 
 Each of those dictionaries represents an object, with the keys corresponding to
 the attribute names of model objects.
@@ -446,10 +446,10 @@
 
 .. versionadded:: 1.0
 
-This is similar to ``values()`` except that instead of returning a list of
-dictionaries, it returns a list of tuples. Each tuple contains the value from
-the respective field passed into the ``values_list()`` call -- so the first
-item is the first field, etc. For example::
+This is similar to ``values()`` except that instead of returning dictionaries,
+it returns tuples when iterated over. Each tuple contains the value from the
+respective field passed into the ``values_list()`` call -- so the first item is
+the first field, etc. For example::
 
 >>> Entry.objects.values_list('id', 'headline')
 [(1, u'First entry'), ...]

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13071: NullBooleanField save error in Admin?

[Django]

#13071: NullBooleanField save error in Admin?
--+-
 Reporter:  Ed Hagen  |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Contrib apps  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have a model field defined thus:

 {{{
 benefit = models.NullBooleanField()
 }}}

 In django 1.1 and 1.2 pre-alpha, nulls were displayed with a "?" icon
 in list view. In the Admin change form, a pop-up menu appeared with 3
 options (Unknown, Yes, No). Setting to "Unknown" and saving did not
 generate any errors.

 I then updated to django 1.2  beta 1 SVN-12738. Nulls are now
 displayed with "(None)". When I try and set this field to "Unknown"
 using the popup menu, and then save in the Admin, I get the following
 error:

 "This field cannot be blank."

 I get this same error when I try and add a new record in the Admin.

 I am using python 2.5.1 on Mac OS X and sqlite3.

-- 
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-upda...@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] r12742 - django/trunk/docs/releases

[noreply]

Author: mtredinnick
Date: 2010-03-09 21:12:48 -0600 (Tue, 09 Mar 2010)
New Revision: 12742

Modified:
   django/trunk/docs/releases/1.2.txt
Log:
Updated syndication framework porting notes.

This is based on some experience porting older code and trying to work
out why my feed content was empty.

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2010-03-10 00:58:05 UTC (rev 12741)
+++ django/trunk/docs/releases/1.2.txt  2010-03-10 03:12:48 UTC (rev 12742)
@@ -508,9 +508,14 @@
 # ...
 )
 
-If you currently use the ``feed()`` view, the ``LatestEntries`` class
-would not need to be modified apart from subclassing the new
-:class:`~django.contrib.syndication.views.Feed` class.
+If you currently use the ``feed()`` view, the ``LatestEntries`` class would
+often not need to be modified apart from subclassing the new
+:class:`~django.contrib.syndication.views.Feed` class. The exception is if
+Django was automatically working out the name of the template to use to render
+the feed's description and title elements (if you were not specifying the
+``title_template`` and ``description_template`` attributes). You should ensure
+that you always specify ``title_template`` and ``description_template``
+attributes, or provide ``item_title()`` and ``item_description()`` methods.
 
 However, ``LatestEntriesByCategory`` uses the ``get_object()`` method
 with the ``bits`` argument to specify a specific category to show. In

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13070: Wrong exception on django.contrib.gis from SVN

[Django]

#13070: Wrong exception on django.contrib.gis from SVN
+---
  Reporter:  Guilherme Gondim (semente)   |   
  Owner:  nobody   
Status:  new| 
Milestone:  1.2  
 Component:  GIS|   
Version:  SVN  
Resolution: |  
Keywords:  geodjango
 Stage:  Unreviewed | 
Has_patch:  0
Needs_docs:  0  |   
Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by Guilherme Gondim (semente) ):

  * 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-upda...@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] #13070: Wrong exception on django.contrib.gis from SVN

[Django]

#13070: Wrong exception on django.contrib.gis from SVN
---+
 Reporter:  Guilherme Gondim (semente)   |   Owner:  
nobody
   Status:  new|   Milestone:  
1.2   
Component:  GIS| Version:  
SVN   
 Keywords:  geodjango  |   Stage:  
Unreviewed
Has_patch:  0  |  
---+
 Hi guys, I can't use the gis app with Django trunk. The same project works
 fine with Django 1.1.

 See the traceback: http://dpaste.com/hold/170253/

-- 
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-upda...@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] #13064: Portuguese translation patch for Django 1.2

[Django]

#13064: Portuguese translation patch for Django 1.2
---+
  Reporter:  nmariz| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Translations  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * component:  Uncategorized => Translations

-- 
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-upda...@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] #13069: Update on Primary Key performs Insert

[Django]

#13069: Update on Primary Key performs Insert
---+
  Reporter:  j.do...@cs.ucl.ac.uk  | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Uncategorized |   Version:  1.1

Resolution:  invalid   |  Keywords:  Primary Key, 
Update, Insert
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Replying to [comment:1 russellm]:
 > This is behaving as designed.

 If this is the case, I do question such design. Primary Key should be
 usable as a holder of values, not only as an ID column for row of values
 (I can sense the same idea being enforced as in auto_id column...).

-- 
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-upda...@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] #11957: runserver must be restarted after error in admin.py

[Django]

#11957: runserver must be restarted after error in admin.py
+---
  Reporter:  carljm | Owner:  brosner
Status:  assigned   | Milestone:  1.2
 Component:  django-admin.py runserver  |   Version:  1.1
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by brosner):

  * milestone:  => 1.2

-- 
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-upda...@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] r12741 - in django/trunk/docs: ref/contrib ref/templates releases

[noreply]

Author: mtredinnick
Date: 2010-03-09 18:58:05 -0600 (Tue, 09 Mar 2010)
New Revision: 12741

Modified:
   django/trunk/docs/ref/contrib/flatpages.txt
   django/trunk/docs/ref/templates/api.txt
   django/trunk/docs/releases/1.2.txt
Log:
Fixed three small doc markup errors.

Modified: django/trunk/docs/ref/contrib/flatpages.txt
===
--- django/trunk/docs/ref/contrib/flatpages.txt 2010-03-09 22:59:02 UTC (rev 
12740)
+++ django/trunk/docs/ref/contrib/flatpages.txt 2010-03-10 00:58:05 UTC (rev 
12741)
@@ -84,7 +84,7 @@
 
Because the ``FlatpageFallbackMiddleware`` is applied only after
URL resolution has failed and produced a 404, the response it
-   returns will not apply any :ref:`view middleware `
+   returns will not apply any :ref:`view middleware `
methods. Only requests which are successfully routed to a view via
normal URL resolution apply view middleware.
 

Modified: django/trunk/docs/ref/templates/api.txt
===
--- django/trunk/docs/ref/templates/api.txt 2010-03-09 22:59:02 UTC (rev 
12740)
+++ django/trunk/docs/ref/templates/api.txt 2010-03-10 00:58:05 UTC (rev 
12741)
@@ -336,6 +336,7 @@
 below.
 
 .. admonition:: When context processors are applied
+
 When you use ``RequestContext``, the variables you supply directly
 are added first, followed any variables supplied by context
 processors. This means that a context processor may overwrite a

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2010-03-09 22:59:02 UTC (rev 12740)
+++ django/trunk/docs/releases/1.2.txt  2010-03-10 00:58:05 UTC (rev 12741)
@@ -638,7 +638,7 @@
 
 The operators supported are ``==``, ``!=``, ``<``, ``>``, ``<=``, ``>=``,
 ``in`` and ``not in``, all of which work like the Python operators, in addition
- to ``and``, ``or`` and ``not``, which were already supported.
+to ``and``, ``or`` and ``not``, which were already supported.
 
 Also, filters may now be used in the ``if`` expression. For example:
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13069: Update on Primary Key performs Insert

[Django]

#13069: Update on Primary Key performs Insert
---+
  Reporter:  j.do...@cs.ucl.ac.uk  | Owner:  nobody 

Status:  closed| Milestone: 

 Component:  Uncategorized |   Version:  1.1

Resolution:  invalid   |  Keywords:  Primary Key, 
Update, Insert
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This is behaving as designed.

-- 
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-upda...@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] #13069: Update on Primary Key performs Insert

[Django]

#13069: Update on Primary Key performs Insert
-+--
 Reporter:  j.do...@cs.ucl.ac.uk |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.1   
 Keywords:  Primary Key, Update, Insert  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 When having a simple table with one column that is set to
 primary_key=True, changing its value in admin pages executes an insert
 instead of an update. According to the documentation:
 http://docs.djangoproject.com/en/dev/ref/models/instances/#how-django-
 knows-to-update-vs-insert I believe this behaviour is wrong.

 Reproduction Steps:
 1) Create simple model with one column primary_key=True (tested on
 charfield)
 2) Insert value in the admin page
 3) Attempt to change the value

 Expected Result:
 - New value replaces the old one

 Actual Result:
 - New row is added, the old value stays in the DB 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-upda...@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] #13068: The "Add another [inline object]" javascript doesn't respect prepopulated_fields settings

[Django]

#13068: The "Add another [inline object]" javascript doesn't respect
prepopulated_fields settings
--+-
 Reporter:  hejsan|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If I have an inline form with a prepopulated field, i.e:
 [[BR]]
 {{{
 class SomethingInline(admin.TabularInline):
 model = Something
 prepopulated_fields = {'title_slug': ('title',)}
 extra = 2
 }}}
 Then the extra inlines added by the new javascript dont automatically
 populate the title_slug field when entering a title.

 BTW: The alternating row colors also dissappear for me in firefox when I
 click "Add another.."

-- 
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-upda...@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] #13067: make bulk-deletion lots faster

[Django]

#13067: make bulk-deletion lots faster
--+-
 Reporter:  carljm|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Model._collect_sub_objects is called separately for every individual
 object-to-be-deleted, and so every relation is followed and queried once
 for every individual object. It is possible to condense those queries down
 to a single bulk query per related model, which should result in massive
 speedups for large bulk QuerySet deletions with related objects. Even
 single-object deletions will be significantly faster if they have a large
 number of related objects to be cascade-deleted that themselves have
 relations.

 Alex Gaynor and I have been discussing implementation ideas, including how
 to do this without negatively impacting the fix for #6191.

-- 
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-upda...@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] r12740 - in django/branches/releases/1.1.X: . django/forms tests/regressiontests/forms

[noreply]

Author: lukeplant
Date: 2010-03-09 16:59:02 -0600 (Tue, 09 Mar 2010)
New Revision: 12740

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/forms/widgets.py
   django/branches/releases/1.1.X/tests/regressiontests/forms/tests.py
   django/branches/releases/1.1.X/tests/regressiontests/forms/widgets.py
Log:
[1.1.X] Fixed #12048 - MultiWidget does not define `__deepcopy__`
  
Thanks to powderflask for report, test case and initial patch.

Backport of [12739] from trunk



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12526,12528,12533,12535,12537,12539,12541,12548,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12526,12528,12533,12535,12537,12539,12541,12548,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737,12739

Modified: django/branches/releases/1.1.X/django/forms/widgets.py
===
--- django/branches/releases/1.1.X/django/forms/widgets.py  2010-03-09 
22:52:04 UTC (rev 12739)
+++ django/branches/releases/1.1.X/django/forms/widgets.py  2010-03-09 
22:59:02 UTC (rev 12740)
@@ -744,6 +744,11 @@
 media = media + w.media
 return media
 media = property(_get_media)
+
+def __deepcopy__(self, memo):
+obj = super(MultiWidget, self).__deepcopy__(memo)
+obj.widgets = copy.deepcopy(self.widgets)
+return obj
 
 class SplitDateTimeWidget(MultiWidget):
 """

Modified: django/branches/releases/1.1.X/tests/regressiontests/forms/tests.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/forms/tests.py 
2010-03-09 22:52:04 UTC (rev 12739)
+++ django/branches/releases/1.1.X/tests/regressiontests/forms/tests.py 
2010-03-09 22:59:02 UTC (rev 12740)
@@ -32,6 +32,8 @@
 from formsets import tests as formset_tests
 from media import media_tests
 
+from widgets import WidgetTests
+
 __test__ = {
 'extra_tests': extra_tests,
 '

[Changeset] r12739 - in django/trunk: django/forms tests/regressiontests/forms

[noreply]

Author: lukeplant
Date: 2010-03-09 16:52:04 -0600 (Tue, 09 Mar 2010)
New Revision: 12739

Modified:
   django/trunk/django/forms/widgets.py
   django/trunk/tests/regressiontests/forms/tests.py
   django/trunk/tests/regressiontests/forms/widgets.py
Log:
Fixed #12048 - MultiWidget does not define `__deepcopy__`

Thanks to powderflask for report, test case and initial patch



Modified: django/trunk/django/forms/widgets.py
===
--- django/trunk/django/forms/widgets.py2010-03-09 14:49:50 UTC (rev 
12738)
+++ django/trunk/django/forms/widgets.py2010-03-09 22:52:04 UTC (rev 
12739)
@@ -738,6 +738,11 @@
 media = media + w.media
 return media
 media = property(_get_media)
+
+def __deepcopy__(self, memo):
+obj = super(MultiWidget, self).__deepcopy__(memo)
+obj.widgets = copy.deepcopy(self.widgets)
+return obj
 
 class SplitDateTimeWidget(MultiWidget):
 """

Modified: django/trunk/tests/regressiontests/forms/tests.py
===
--- django/trunk/tests/regressiontests/forms/tests.py   2010-03-09 14:49:50 UTC 
(rev 12738)
+++ django/trunk/tests/regressiontests/forms/tests.py   2010-03-09 22:52:04 UTC 
(rev 12739)
@@ -39,6 +39,7 @@
 
 from fields import FieldsTests
 from validators import TestFieldWithValidators
+from widgets import WidgetTests
 
 __test__ = {
 'extra_tests': extra_tests,

Modified: django/trunk/tests/regressiontests/forms/widgets.py
===
--- django/trunk/tests/regressiontests/forms/widgets.py 2010-03-09 14:49:50 UTC 
(rev 12738)
+++ django/trunk/tests/regressiontests/forms/widgets.py 2010-03-09 22:52:04 UTC 
(rev 12739)
@@ -1269,3 +1269,43 @@
 
 """
 
+
+from django.utils import copycompat as copy
+from unittest import TestCase
+from django import forms
+
+
+class SelectAndTextWidget(forms.MultiWidget):
+"""
+MultiWidget subclass
+"""
+def __init__(self, choices=[]):
+widgets = [
+forms.RadioSelect(choices=choices),
+forms.TextInput
+]
+super(SelectAndTextWidget, self).__init__(widgets)
+
+def _set_choices(self, choices):
+"""
+When choices are set for this widget, we want to pass those along to 
the Select widget
+"""
+self.widgets[0].choices = choices
+def _get_choices(self):
+"""
+The choices for this widget are the Select widget's choices
+"""
+return self.widgets[0].choices
+choices = property(_get_choices, _set_choices)
+
+
+class WidgetTests(TestCase):
+
+def test_12048(self):
+# See ticket #12048.
+w1 = SelectAndTextWidget(choices=[1,2,3])
+w2 = copy.deepcopy(w1)
+w2.choices = [4,5,6]
+# w2 ought to be independent of w1, since MultiWidget ought
+# to make a copy of its sub-widgets when it is copied.
+self.assertEqual(w1.choices, [1,2,3])

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13066: cache.get and cache.set should have consistent key rules across different backends

[Django]

#13066: cache.get and cache.set should have consistent key rules across 
different
backends
--+-
 Reporter:  rbanffy   |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Cache system  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 As it is now, cache.get and cache.set accept keys with spaces when
 CACHE_BACKEND is set to 'locmem://', but memcached complains of keys with
 spaces. This makes tests work on a non-memcached setup (i.e. development
 workstation) and fail on the server (using memcached)

-- 
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-upda...@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] #12134: contrib.admin.RelatedFieldWidgetWrapper.__deepcopy__() should copy() the widget attrs

[Django]

#12134: contrib.admin.RelatedFieldWidgetWrapper.__deepcopy__() should copy() the
widget attrs
---+
  Reporter:  ubernostrum   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by lukeplant):

 I think we need some more analysis of why this patch is correct/needed.
 Here are some simplified extracts of current code:

 {{{
 #!python
 class RelatedFieldWidgetWrapper(forms.Widget):
 def __init__(self, widget, rel, admin_site):
 self.attrs = widget.attrs
 self.widget = widget
 # 

 def __deepcopy__(self, memo):
 obj = copy.copy(self)
 obj.widget = copy.deepcopy(self.widget, memo)
 obj.attrs = self.widget.attrs
 memo[id(self)] = obj
 return obj
 }}}

 This means:
 {{{
 #!python
 wrapper1 = RelatedFieldWidgetWrapper(some_widget, some_rel,
 some_admin_site)
 wrapper2 = copy.deepcopy(wrapper1) # as happens when widget is copied via
 BaseForm.__init__()

 assert wrapper1.attrs is wrapper1.widget.attrs
 assert wrapper2.attrs is wrapper2.widget.attrs
 assert wrapper1.widget is not wrapper2.widget

 }}}

 That all seems to be correct.  The attached patch would actually break the
 second assert, which I'm pretty sure will break the ability of the class
 instance to work as a wrapper.

-- 
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-upda...@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] #11183: BaseForm init leaves pointers pointing back to base_fields when widget is a Select

[Django]

#11183: BaseForm init leaves pointers pointing back to base_fields when widget 
is a
Select
-+--
  Reporter:  margieroginski  | Owner:  lukeplant
Status:  closed  | Milestone:  1.2  
 Component:  Forms   |   Version:  1.0  
Resolution:  fixed   |  Keywords:   
 Stage:  Accepted| Has_patch:  0
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Comment (by lukeplant):

 For the record, in reply to Alex:

  - There is a lot of discussion on this on #5505
  - relevant commits are [6156], [6415], [6450]

 The current state is that if I remove the `__deepcopy__` from Widget and
 subclasses I don't actually get any failing tests, but there may not be
 any specific tests for the problems of not defining that method.  If I
 remove the `__deepcopy__` from Field and subclasses I get lots of failing
 tests and exceptions (mainly seem to be about copying regexes).

-- 
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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Replying to [comment:20 adamnelson]:
 > Is all that's being asked is whether to change !ValidationError back to
 !ValueError ?  If so that seems like the way to go.

 I don't know what you are proposing there exactly.

 I'd object to changing fields (such as !DecimalField) that currently raise
 !ValidationError for bad data to instead raise !ValueError, for the same
 reason as I've raised concerns about the reverse change: it would break
 previously working code.

 If you're not proposing that but rather proposing that these particular
 fields that currently unfortunately raise !ValueError instead of the
 !ValidationError that would be more proper, continue to raise !ValueError
 while other fields continue to raise !ValidationError, then I'm not sure
 what the change buys us, exactly. I thought one of the aims was to bring
 consistency to the API across the field types?

 Having !ValidationError inherit from !ValueError might be a possibility,
 but I haven't had time to think through whether that introduces any of its
 own problems.

-- 
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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Leo):

 @adamnelson Thanks for weighing in, however making the code not throw a
 `ValueError` is the heart of the patch. All that does is wrap the
 `TypeError`s but doesn't fix the implementation from an API perspective.

 @kmtracey, I strongly agree that this behavior change needs documentation.
 I left it out of the original patch since I strongly suspect that what I
 write will need to be re-written by a core dev anyways to fit style and
 consistency guidelines. If that's not the case, I'm happy to take a crack
 at 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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 Is all that's being asked is whether to change !ValidationError back to
 !ValueError ?  If so that seems like the way to 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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 In my view it is not a waste of time to ensure we don't blindside users
 with backwards-incompatible changes. Note we do attempt to document all
 backwards incompatible changes, so that people who might run into them may
 have a clue, if they read the release notes, that they could run into them
 when updating. There are no such notes included with this patch, nor was
 there even mention of the possibility of this introducing a backwards-
 incompatibility, until I brought it up. If this is to be done for 1.2, it
 needs documentation of the backwards incompatibility introduced.

 (Note claiming it's perfectly OK to add more backwards-incompatible
 changes into 1.2 because it already has so many is fallacious: each one is
 considered on its own merits. If anything I'd argue that the reasons needs
 to be even stronger as the list gets longer, not the other way around.)

 Alternatively, if there is a way to accomplish the bulk of what this
 ticket was aiming for without introducing a backwards-incompatibility,
 that would be even better, in my opinion. Hopefully I've clarified above
 what I mean by backwards-incompatible. (It is not true that every behavior
 change introduced by a bugfix introduces a backwards-incompatibility.)

 As for process, what's needed is consensus among the core devs. What we've
 got now is one (me) who has expressed concerns and none who have come
 forward to say my concerns are unfounded or overblown. While Russ accepted
 the ticket, I do not know if he was aware of the backwards-incompatibility
 introduced and did not think it enough of a problem to worry about, or if
 he did not notice it.

 I won't stand in the way if others on the core think this is a change
 worth making, even in light of the problems it may cause for existing
 code. I'll just strongly urge that it at least needs documentation of the
 backwards incompatibility.

-- 
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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 Maybe the compromise is to revert the !ValidationError to !ValueError
 change and leave everything else as is?  ValidationError isn't in the
 standard library, so it's not the craziest thing to just stick with
 ValueError for milestone:1.2 and make a new ticket to rationalize
 exceptions in Django.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 @kmtracey While it may in theory be true that milestone:1.2 is 'minor',
 that's not true in practice.  Python 2.3 support is being dropped as well
 as all sorts of major backwards incompatible changes.  Anybody who wrote a
 workaround for this behavior can stick with milestone:1.1 for an extended
 period of time while updating their codebase.  Well maintained apps can
 move to this format in short order without losing milestone:1.0
 compatibility.  I would understand not making a backwards incompatible
 change in milestone:1.1.1 , but for something as big as milestone:1.2 with
 so many other major incompatibilities, we're wasting time.

 In addition, russelm accepted the ticket and assigned it to milestone:1.2
 .  That should be sufficient to get the ticket merged.

-- 
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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Leo):

 Replying to [comment:15 kmtracey]:
 > I'm saying it's policy not to introduce backwards-incompatible changes
 in a micro or minor release update, and therefore I have concerns about
 this patch, because it seems to me it may likely cause previously robust
 application code to start raising exceptions.


 I agree that it will cause some applications to start raising exceptions.
 I think your concerns are vary valid and critical to consider for a
 project like Django. I believe that its a better choice for Django to make
 this change in this release and take the impact of introducing this
 behavior change especially since non-trivial parts of the DB architecture
 have been worked on for this release (including the very functions this
 patch changes).

 > You say the consequences of not fixing this bug are significant. What
 I'm saying is we cannot now break code in the wild that has already been
 written to accommodate those consequences.


 Sure, but that's true for virtually any bugfix so this isn't an absolute.
 This is a discussion with a range of impacts of either making the change
 or not making it.

 > This code catches !ValueError there because that is the exception that
 has in fact been raised in observed cases where bad data is present in
 `request.GET['c']`.
 > It doesn't catch !ValidationError because that has not been an exception
 observed to be raised.


 In my experience the approach of seeing what exceptions I can observe has
 not been a great way figure out what exceptions to catch in the code that
 I write. I've found that fairly often I either overlook a potential
 failure case or do not fully understand (or sometimes don't even have
 access to) how the code I'm working with behaves. This has resulted in me
 preferring to think about interfaces and how the code should behave and
 defining those interfaces in one form or another.

 > Now, it may well be possible to cause a !ValidationError here, since a
 custom comments model may have a custom pk field of some non-standard
 type, a type that raises !ValidationError on being handed invalid data.
 But for a typical auto-generated pk field, I cannot find any case where a
 querystring parameter value (which will be a unicode string) containing
 'bad' data generates anything other than a !ValueError. (Based on prior
 experience I thought !TypeError was another possibility but I can't even
 get that one to be raised.)


 It doesn't need to be a very non-standard field. A `DecimalField` will
 cause the problem. It's a slightly larger test case to create a custom
 `Comments` model but I've attached a very simple one that breaks another
 part of the comments application that also doesn't catch `ValidationError`
 properly.

 > So my concern is that there may be Django users with apps with code
 written much like this, and I do not think they will be pleased if we now
 change what gets raised there from a !ValueError to a !ValidationError.
 That change will cause their code, which previously gracefully handled
 being handed bad data values, to now start returning server error pages. I
 don't think they will see that change as an improvement.


 I think you're right. Very few developers are happy when their code
 doesn't work as they expect. In my experience the best way to prevent that
 is to have interfaces on commonly used components. If this change is
 properly messaged in the release notes I believe that it will make Django
 users happy when they can replace rather ugly and patched code with much
 cleaner code that represents a contract and gives them more assurance that
 their app won't break.

 I respect your concerns about this patch and I think we're both striving
 to make Django better but I suspect we may not come to agreement on this
 issue so I'm wondering what the right next step is given Django's process.
 Should this be brought up for discussion on django-dev? is there a vote by
 the core committees? does the release manager decide this?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Dj

Re: [Django] #13007: Django fails to log in when a cookie is set on the same domain containing a colon

[Django]

#13007: Django fails to log in when a cookie is set on the same domain 
containing a
colon
+---
  Reporter:  Warlax | Owner:  nobody 
Status:  reopened   | Milestone: 
 Component:  HTTP handling  |   Version:  1.1
Resolution: |  Keywords:  cookies
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by Warlax):

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

Comment:

 Create a standard django app with the default auth system

 create a view that is @login_required

 MANUALLY create a cookie in ur browser under the url django is servered
 at, ie 127.0.0.1:8000

 create this cookie
 "org.ditchnet.jsp.tabs:task-details" with a value of anything, eg
 "231432423"

 try and log into the django app. you will not be able to view the page
 behind the login required decorator

-- 
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-upda...@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] #11716: Various methods in django.db.models.fields don't wrap ValueErrors and allow them to escape

[Django]

#11716: Various methods in django.db.models.fields don't wrap ValueErrors and 
allow
them to escape
---+
  Reporter:  Leo   | Owner:  Leo
Status:  assigned  | Milestone:  1.2
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 I'm saying it's policy not to introduce backwards-incompatible changes in
 a micro or minor release update, and therefore I have concerns about this
 patch, because it seems to me it may likely cause previously robust
 application code to start raising exceptions.

 You say the consequences of not fixing this bug are significant. What I'm
 saying is we cannot now break code in the wild that has already been
 written to accommodate those consequences. Code that likely looks similar
 to the comments code:

 {{{
 #!python
 def confirmed(request):
 comment = None
 if 'c' in request.GET:
 try:
 comment =
 comments.get_model().objects.get(pk=request.GET['c'])
 except (ObjectDoesNotExist, ValueError):
 pass
 return render_to_response(template,
 {'comment': comment},
 context_instance=RequestContext(request)
 )
 }}}

 This code catches !ValueError there because that is the exception that has
 in fact been raised in observed cases where bad data is present in
 `request.GET['c']`. It doesn't catch !ValidationError because that has not
 been an exception observed to be raised.

 Now, it may well be possible to cause a !ValidationError here, since a
 custom comments model may have a custom pk field of some non-standard
 type, a type that raises !ValidationError on being handed invalid data.
 But for a typical auto-generated pk field, I cannot find any case where a
 querystring parameter value (which will be a unicode string) containing
 'bad' data generates anything other than a !ValueError. (Based on prior
 experience I thought !TypeError was another possibility but I can't even
 get that one to be raised.)

 So my concern is that there may be Django users with apps with code
 written much like this, and I do not think they will be pleased if we now
 change what gets raised there from a !ValueError to a !ValidationError.
 That change will cause their code, which previously gracefully handled
 being handed bad data values, to now start returning server error pages. I
 don't think they will see that change as an improvement.

-- 
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-upda...@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] #13040: Change in Sphinx rendering of current module

[Django]

#13040: Change in Sphinx rendering of current module
+---
  Reporter:  stherrien  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by stherrien):

  * status:  closed => reopened
  * resolution:  wontfix =>
  * summary:  Would like to add import statments for class documentation
  where needed => Change in Sphinx rendering of
  current module

Comment:

 I purpose changing the Sphinx rendering of current modules I think this is
 helpful to show the full paths in the docs.

-- 
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-upda...@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] r12738 - in django/branches/releases/1.1.X: . django/db/backends

[noreply]

Author: kmtracey
Date: 2010-03-09 08:49:50 -0600 (Tue, 09 Mar 2010)
New Revision: 12738

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/db/backends/__init__.py
Log:
[1.1.X] Changed last_executed_query to avoid raising exceptions on 
non-utf8-encoded parameter data. 

r12737 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12526,12528,12533,12535,12537,12539,12541,12548,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12398,12405,12408-12411,12419-12420,12423,12425-12426,12429,12434,12436,12439-12442,12447-12448,12457,12461-12464,12467,12471,12473,12475,12484,12489-12490,12492,12497-12498,12502,12505,12513,12515-12516,12518,12523,12526,12528,12533,12535,12537,12539,12541,12548,12553,12556,12558-12560,12562,12567,12569-12570,12573,12576,12579,12581,12584,12598-12599,12602,12605,12614,12616,12621-12622,12627,12630-12631,12635,12637,12639,12641,12644,12646,12648,12650,12652,12654,12657,12659,12661,12663,12665,12667,12669,12671,12673,12676,12679,12681,12683,12686,12688,12694,12696,12698,12700,12704-12705,12710-12712,12719,12721,12723,12725-12726,12728,12733-12734,12737

Modified: django/branches/releases/1.1.X/django/db/backends/__init__.py
===
--- django/branches/releases/1.1.X/django/db/backends/__init__.py   
2010-03-09 14:46:33 UTC (rev 12737)
+++ django/branches/releases/1.1.X/django/db/backends/__init__.py   
2010-03-09 14:49:50 UTC (rev 12738)
@@ -208,7 +208,7 @@
 from django.utils.encoding import smart_unicode, force_unicode
 
 # Convert params to contain Unicode values.
-to_unicode = lambda s: force_unicode(s, strings_only=True)
+to_unicode = lambda s: force_unicode(s, strings_only=True, 
errors='replace')
 if isinstance(params, (list, tuple)):
 u_params = tuple([to_unicode(val) for val in params])
 else:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
---+
  Reporter:  paltman   | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Design decision needed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by slav0nic):

 * cc: slav0n...@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-upda...@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] r12737 - django/trunk/django/db/backends

[noreply]

Author: kmtracey
Date: 2010-03-09 08:46:33 -0600 (Tue, 09 Mar 2010)
New Revision: 12737

Modified:
   django/trunk/django/db/backends/__init__.py
Log:
Changed last_executed_query to avoid raising exceptions on non-utf8-encoded 
parameter data. 


Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2010-03-09 02:03:09 UTC (rev 
12736)
+++ django/trunk/django/db/backends/__init__.py 2010-03-09 14:46:33 UTC (rev 
12737)
@@ -206,7 +206,7 @@
 from django.utils.encoding import smart_unicode, force_unicode
 
 # Convert params to contain Unicode values.
-to_unicode = lambda s: force_unicode(s, strings_only=True)
+to_unicode = lambda s: force_unicode(s, strings_only=True, 
errors='replace')
 if isinstance(params, (list, tuple)):
 u_params = tuple([to_unicode(val) for val in params])
 else:

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13065: Brazilian Portuguese locale updated

[Django]

#13065: Brazilian Portuguese locale updated
---+
 Reporter:  Guilherme Gondim (semente)   |   Owner:  
nobody
   Status:  new|   Milestone:  
1.2   
Component:  Translations   | Version:  
SVN   
 Keywords:  pt_BR  |   Stage:  
Unreviewed
Has_patch:  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-upda...@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] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
---+
  Reporter:  paltman   | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Design decision needed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: t.dja...@sandbox.cz (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-upda...@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] #13064: Portuguese translation patch for Django 1.2

[Django]

#13064: Portuguese translation patch for Django 1.2
---+
 Reporter:  nmariz |   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  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-upda...@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] #12945: url tag breaks on spaces between delimiting commas since [12503]

[Django]

#12945: url tag breaks on spaces between delimiting commas since [12503]
--+-
  Reporter:  jklaiho  | Owner:  coleifer  
Status:  assigned | Milestone:  1.2   
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:  url tag pycamp2010
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by anonymous):

 * cc: a...@gc-web.de (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-upda...@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] #13064: Portuguese translation patch for Django 1.2

[Django]

#13064: Portuguese translation patch for Django 1.2
+---
  Reporter:  nmariz | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * 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-upda...@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] #12822: DatabaseError: aggregates not allowed in WHERE clause

[Django]

#12822: DatabaseError: aggregates not allowed in WHERE clause
--+-
  Reporter:  mat  | Owner: 
Status:  new  | Milestone:  1.2
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by mat):

  * version:  1.2-beta => SVN

-- 
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-upda...@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] #12422: Django overrides the default email charset behaviour for utf-8

[Django]

#12422: Django overrides the default email charset behaviour for utf-8
---+
  Reporter:  simonb| Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.core.mail  |   Version:  1.1  
Resolution:|  Keywords:  charset utf-8
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by simonb):

 * cc: bno...@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-upda...@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] #13060: ManagementForm exception in case of bad prefix should be easier to understand

[Django]

#13060: ManagementForm exception in case of bad prefix should be easier to
understand
---+
  Reporter:  Karel | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Forms |   Version: 
 
Resolution:|  Keywords:  formset, ValidationError, 
ManagementForm
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Not sure I completely agree with the suggested fix, but yes -- the error
 on failure of the management form could be a little more helpful, at the
 very least naming the field that is missing or 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-upda...@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] #13057: Missing validation of child models

[Django]

#13057: Missing validation of child models
---+
  Reporter:  vzima | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * 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-upda...@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] #13061: Default login template is on bad place - registration/login.html TemplateDoesNotExist

[Django]

#13061: Default login template is on bad place - registration/login.html
TemplateDoesNotExist
-+--
  Reporter:  sopuch  | Owner:  nobody
Status:  closed  | Milestone:  1.2   
 Component:  Authentication  |   Version:  1.1   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 Omitted on purpose. We can't provide a template that will work on every
 site. You need to provide the template, and registration/login.html is a
 default suggested location.

-- 
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-upda...@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] #13062: Can't see PendingDeprecationWarnings in the development server on Linux

[Django]

#13062: Can't see PendingDeprecationWarnings in the development server on Linux
+---
  Reporter:  gremmie| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * 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-upda...@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] #13063: Documentation Clarification - Django 1.1.1 Tutorial Part 1 and __unicode__ methods

[Django]

#13063: Documentation Clarification - Django 1.1.1 Tutorial Part 1 and 
__unicode__
methods
+---
  Reporter:  rwalsh | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 The docs specifically say "Save these changes and start a new Python
 interactive shell by running python manage.py shell again", just after the
 instructions to add the unicode method.

-- 
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-upda...@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.