Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anih):

 Replying to [comment:41 liangent]:
 > Replying to [comment:37 anih]:
 > (note: 1. 'key 1' is the primary key; 2. i'm using mysql:
 5.0.67-0ubuntu6)
 >
 > i think it has nothing to do with the models.
 >
 > as i know, django try to SELECT a row when we're going to .save() to
 know if the row exists. however, because i used SELECT FOR UPDATE, mysql
 locked the row, and django cannot find it with SELECT, so django decides
 to INSERT. since the field 'id' in object 't' has been set and value is
 assigned to an existing row ('t' was got from a SELECT FOR UPDATE), an
 IntegrityError is raised.

 problem is how mysql treats rows select with for update statment:
 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-
 and-for-update/

-- 
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] r9973 - in django/branches/releases/1.0.X: django/db/models tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-04 01:24:30 -0600 (Wed, 04 Mar 2009)
New Revision: 9973

Modified:
   django/branches/releases/1.0.X/django/db/models/base.py
   
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
Log:
[1.0.X] Fixed #10406 -- Fixed some problems with model inheritance and pk 
fields.

Manually specifying both a OneToOneField(parent_link=True) and separate a
primary key field was causing invalid SQL to be generated. Thanks to Ramiro
Morales for some analysis on this one.

Backport of r9971 from trunk.

Modified: django/branches/releases/1.0.X/django/db/models/base.py
===
--- django/branches/releases/1.0.X/django/db/models/base.py 2009-03-04 
07:23:18 UTC (rev 9972)
+++ django/branches/releases/1.0.X/django/db/models/base.py 2009-03-04 
07:24:30 UTC (rev 9973)
@@ -98,8 +98,6 @@
 # Concrete classes...
 if base in o2o_map:
 field = o2o_map[base]
-field.primary_key = True
-new_class._meta.setup_pk(field)
 else:
 attr_name = '%s_ptr' % base._meta.module_name
 field = OneToOneField(base, name=attr_name,

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 07:23:18 UTC (rev 9972)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 07:24:30 UTC (rev 9973)
@@ -43,6 +43,16 @@
 def __unicode__(self):
 return u"%s the parking lot" % self.name
 
+class ParkingLot2(Place):
+# In lieu of any other connector, an existing OneToOneField will be
+# promoted to the primary key.
+parent = models.OneToOneField(Place)
+
+class ParkingLot3(Place):
+# The parent_link connector need not be the pk on the model.
+primary_key = models.AutoField(primary_key=True)
+parent = models.OneToOneField(Place, parent_link=True)
+
 class Supplier(models.Model):
 restaurant = models.ForeignKey(Restaurant)
 
@@ -293,5 +303,20 @@
 >>> DerivedM.objects.all()
 []
 
+# Regression tests for #10406
+
+# If there's a one-to-one link between a child model and the parent and no
+# explicit pk declared, we can use the one-to-one link as the pk on the child.
+# The ParkingLot2 model shows this behaviour.
+>>> ParkingLot2._meta.pk.name
+"parent"
+
+# However, the connector from child to parent need not be the pk on the child
+# at all.
+>>> ParkingLot3._meta.pk.name
+"primary_key"
+>>> ParkingLot3._meta.get_ancestor_link(Place).name  # the child->parent link
+"parent"
+
 """}
 


--~--~-~--~~~---~--~~
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] r9972 - in django/branches/releases/1.0.X: django/db/models django/db/models/sql tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-04 01:23:18 -0600 (Wed, 04 Mar 2009)
New Revision: 9972

Modified:
   django/branches/releases/1.0.X/django/db/models/options.py
   django/branches/releases/1.0.X/django/db/models/sql/query.py
   
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
Log:
[1.0.X] Fixed #10251 -- Fixed model inheritance when there's also an explicit 
pk field.

Backport of r9970 from trunk.

Modified: django/branches/releases/1.0.X/django/db/models/options.py
===
--- django/branches/releases/1.0.X/django/db/models/options.py  2009-03-04 
07:21:14 UTC (rev 9971)
+++ django/branches/releases/1.0.X/django/db/models/options.py  2009-03-04 
07:23:18 UTC (rev 9972)
@@ -436,6 +436,21 @@
 result.update(parent._meta.get_parent_list())
 return result
 
+def get_ancestor_link(self, ancestor):
+"""
+Returns the field on the current model which points to the given
+"ancestor". This is possible an indirect link (a pointer to a parent
+model, which points, eventually, to the ancestor). Used when
+constructing table joins for model inheritance.
+
+Returns None if the model isn't an ancestor of this one.
+"""
+if ancestor in self.parents:
+return self.parents[ancestor]
+for parent in self.parents:
+if parent._meta.get_ancestor_link(ancestor):
+return self.parents[parent]
+
 def get_ordered_objects(self):
 "Returns a list of Options objects that are ordered with respect to 
this object."
 if not hasattr(self, '_ordered_objects'):

Modified: django/branches/releases/1.0.X/django/db/models/sql/query.py
===
--- django/branches/releases/1.0.X/django/db/models/sql/query.py
2009-03-04 07:21:14 UTC (rev 9971)
+++ django/branches/releases/1.0.X/django/db/models/sql/query.py
2009-03-04 07:23:18 UTC (rev 9972)
@@ -494,14 +494,14 @@
 aliases = set()
 if start_alias:
 seen = {None: start_alias}
-root_pk = opts.pk.column
 for field, model in opts.get_fields_with_model():
 if start_alias:
 try:
 alias = seen[model]
 except KeyError:
+link_field = opts.get_ancestor_link(model)
 alias = self.join((start_alias, model._meta.db_table,
-root_pk, model._meta.pk.column))
+link_field.column, model._meta.pk.column))
 seen[model] = alias
 else:
 # If we're starting from the base model of the queryset, the
@@ -1005,13 +1005,13 @@
 as_sql()).
 """
 opts = self.model._meta
-root_pk = opts.pk.column
 root_alias = self.tables[0]
 seen = {None: root_alias}
 for field, model in opts.get_fields_with_model():
 if model not in seen:
+link_field = opts.get_ancestor_link(model)
 seen[model] = self.join((root_alias, model._meta.db_table,
-root_pk, model._meta.pk.column))
+link_field.column, model._meta.pk.column))
 self.included_inherited_models = seen
 
 def remove_inherited_models(self):

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 07:21:14 UTC (rev 9971)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 07:23:18 UTC (rev 9972)
@@ -86,7 +86,20 @@
 class QualityControl(Evaluation):
 assignee = models.CharField(max_length=50)
 
+class BaseM(models.Model):
+base_name = models.CharField(max_length=100)
 
+def __unicode__(self):
+return self.base_name
+
+class DerivedM(BaseM):
+customPK = models.IntegerField(primary_key=True)
+derived_name = models.CharField(max_length=100)
+
+def __unicode__(self):
+return "PK = %d, base_name = %s, derived_name = %s" \
+% (self.customPK, self.base_name, self.derived_name)
+
 __test__ = {'API_TESTS':"""
 # Regression for #7350, #7202
 # Check that when you create a Parent object with a specific reference to an
@@ -275,4 +288,10 @@
 >>> ArticleWithAuthor.objects.filter(pk=article.pk).update(headline="Oh, no!")
 1
 
+>>> DerivedM.objects.create(customPK=44, base_name="b1", derived_name="d1")
+
+>>> DerivedM.objects.all()
+[]
+
 """}
+


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to 

[Changeset] r9971 - in django/trunk: django/db/models tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-04 01:21:14 -0600 (Wed, 04 Mar 2009)
New Revision: 9971

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/tests/regressiontests/model_inheritance_regress/models.py
Log:
Fixed #10406 -- Fixed some problems with model inheritance and pk fields.

Manually specifying both a OneToOneField(parent_link=True) and separate a
primary key field was causing invalid SQL to be generated. Thanks to Ramiro
Morales for some analysis on this one.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-03-04 07:20:08 UTC (rev 
9970)
+++ django/trunk/django/db/models/base.py   2009-03-04 07:21:14 UTC (rev 
9971)
@@ -98,8 +98,6 @@
 # Concrete classes...
 if base in o2o_map:
 field = o2o_map[base]
-field.primary_key = True
-new_class._meta.setup_pk(field)
 else:
 attr_name = '%s_ptr' % base._meta.module_name
 field = OneToOneField(base, name=attr_name,

Modified: django/trunk/tests/regressiontests/model_inheritance_regress/models.py
===
--- django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2009-03-04 07:20:08 UTC (rev 9970)
+++ django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2009-03-04 07:21:14 UTC (rev 9971)
@@ -43,6 +43,16 @@
 def __unicode__(self):
 return u"%s the parking lot" % self.name
 
+class ParkingLot2(Place):
+# In lieu of any other connector, an existing OneToOneField will be
+# promoted to the primary key.
+parent = models.OneToOneField(Place)
+
+class ParkingLot3(Place):
+# The parent_link connector need not be the pk on the model.
+primary_key = models.AutoField(primary_key=True)
+parent = models.OneToOneField(Place, parent_link=True)
+
 class Supplier(models.Model):
 restaurant = models.ForeignKey(Restaurant)
 
@@ -293,5 +303,20 @@
 >>> DerivedM.objects.all()
 []
 
+# Regression tests for #10406
+
+# If there's a one-to-one link between a child model and the parent and no
+# explicit pk declared, we can use the one-to-one link as the pk on the child.
+# The ParkingLot2 model shows this behaviour.
+>>> ParkingLot2._meta.pk.name
+"parent"
+
+# However, the connector from child to parent need not be the pk on the child
+# at all.
+>>> ParkingLot3._meta.pk.name
+"primary_key"
+>>> ParkingLot3._meta.get_ancestor_link(Place).name  # the child->parent link
+"parent"
+
 """}
 


--~--~-~--~~~---~--~~
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] r9970 - in django/trunk: django/db/models django/db/models/sql tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-04 01:20:08 -0600 (Wed, 04 Mar 2009)
New Revision: 9970

Modified:
   django/trunk/django/db/models/options.py
   django/trunk/django/db/models/sql/query.py
   django/trunk/tests/regressiontests/model_inheritance_regress/models.py
Log:
Fixed #10251 -- Fixed model inheritance when there's also an explicit pk field.

Modified: django/trunk/django/db/models/options.py
===
--- django/trunk/django/db/models/options.py2009-03-04 05:40:22 UTC (rev 
9969)
+++ django/trunk/django/db/models/options.py2009-03-04 07:20:08 UTC (rev 
9970)
@@ -435,6 +435,21 @@
 result.update(parent._meta.get_parent_list())
 return result
 
+def get_ancestor_link(self, ancestor):
+"""
+Returns the field on the current model which points to the given
+"ancestor". This is possible an indirect link (a pointer to a parent
+model, which points, eventually, to the ancestor). Used when
+constructing table joins for model inheritance.
+
+Returns None if the model isn't an ancestor of this one.
+"""
+if ancestor in self.parents:
+return self.parents[ancestor]
+for parent in self.parents:
+if parent._meta.get_ancestor_link(ancestor):
+return self.parents[parent]
+
 def get_ordered_objects(self):
 "Returns a list of Options objects that are ordered with respect to 
this object."
 if not hasattr(self, '_ordered_objects'):

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2009-03-04 05:40:22 UTC (rev 
9969)
+++ django/trunk/django/db/models/sql/query.py  2009-03-04 07:20:08 UTC (rev 
9970)
@@ -643,14 +643,14 @@
 aliases = set()
 if start_alias:
 seen = {None: start_alias}
-root_pk = opts.pk.column
 for field, model in opts.get_fields_with_model():
 if start_alias:
 try:
 alias = seen[model]
 except KeyError:
+link_field = opts.get_ancestor_link(model)
 alias = self.join((start_alias, model._meta.db_table,
-root_pk, model._meta.pk.column))
+link_field.column, model._meta.pk.column))
 seen[model] = alias
 else:
 # If we're starting from the base model of the queryset, the
@@ -1156,13 +1156,13 @@
 as_sql()).
 """
 opts = self.model._meta
-root_pk = opts.pk.column
 root_alias = self.tables[0]
 seen = {None: root_alias}
 for field, model in opts.get_fields_with_model():
 if model not in seen:
+link_field = opts.get_ancestor_link(model)
 seen[model] = self.join((root_alias, model._meta.db_table,
-root_pk, model._meta.pk.column))
+link_field.column, model._meta.pk.column))
 self.included_inherited_models = seen
 
 def remove_inherited_models(self):

Modified: django/trunk/tests/regressiontests/model_inheritance_regress/models.py
===
--- django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2009-03-04 05:40:22 UTC (rev 9969)
+++ django/trunk/tests/regressiontests/model_inheritance_regress/models.py  
2009-03-04 07:20:08 UTC (rev 9970)
@@ -86,7 +86,20 @@
 class QualityControl(Evaluation):
 assignee = models.CharField(max_length=50)
 
+class BaseM(models.Model):
+base_name = models.CharField(max_length=100)
 
+def __unicode__(self):
+return self.base_name
+
+class DerivedM(BaseM):
+customPK = models.IntegerField(primary_key=True)
+derived_name = models.CharField(max_length=100)
+
+def __unicode__(self):
+return "PK = %d, base_name = %s, derived_name = %s" \
+% (self.customPK, self.base_name, self.derived_name)
+
 __test__ = {'API_TESTS':"""
 # Regression for #7350, #7202
 # Check that when you create a Parent object with a specific reference to an
@@ -275,4 +288,10 @@
 >>> ArticleWithAuthor.objects.filter(pk=article.pk).update(headline="Oh, no!")
 1
 
+>>> DerivedM.objects.create(customPK=44, base_name="b1", derived_name="d1")
+
+>>> DerivedM.objects.all()
+[]
+
 """}
+


--~--~-~--~~~---~--~~
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] #10327: Pass document.domain to popup windows in admin

[Django]

#10327: Pass document.domain to popup windows in admin
---+
  Reporter:  jcassee   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jcassee):

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

Comment:

 Setting `has_patch` and removing `needs_better_patch` to invite patch
 review.

-- 
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] #10327: Pass document.domain to popup windows in admin

[Django]

#10327: Pass document.domain to popup windows in admin
---+
  Reporter:  jcassee   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by jcassee):

 The new patch only appends the `jsdom` query parameter if the Javascript
 domain differs from the location domain. Additionally, it is given its own
 variable in the template context (like `is_popup`). I hope the patch is
 now good enough to be applied, otherwise please indicate how to improve
 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
-~--~~~~--~~--~--~---

[Changeset] r9969 - in django/branches/releases/1.0.X: django/db/models/sql tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-03 23:40:22 -0600 (Tue, 03 Mar 2009)
New Revision: 9969

Modified:
   django/branches/releases/1.0.X/django/db/models/sql/subqueries.py
   
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
Log:
[1.0.X] Changed the row count value returned from update queries in some cases.

If an update only affected an ancestor model (not the child), we were
returning 0 for the number of rows updated. This could have been
misleading if the value is used to detect an update occuring. So we now
return the rowcount from the first non-trivial query that is executed
(if any). Still a slight compromise, but better than what we had.

Backport of r9966 from trunk (turns out this *is* a bugfix, since the returned
rowcount is used in Model.save(force_update=True)).

Modified: django/branches/releases/1.0.X/django/db/models/sql/subqueries.py
===
--- django/branches/releases/1.0.X/django/db/models/sql/subqueries.py   
2009-03-04 05:35:10 UTC (rev 9968)
+++ django/branches/releases/1.0.X/django/db/models/sql/subqueries.py   
2009-03-04 05:40:22 UTC (rev 9969)
@@ -111,14 +111,19 @@
 def execute_sql(self, result_type=None):
 """
 Execute the specified update. Returns the number of rows affected by
-the primary update query (there could be other updates on related
-tables, but their rowcounts are not returned).
+the primary update query. The "primary update query" is the first
+non-empty query that is executed. Row counts for any subsequent,
+related queries are not available.
 """
 cursor = super(UpdateQuery, self).execute_sql(result_type)
 rows = cursor and cursor.rowcount or 0
+is_empty = cursor is None
 del cursor
 for query in self.get_related_updates():
-query.execute_sql(result_type)
+aux_rows = query.execute_sql(result_type)
+if is_empty:
+rows = aux_rows
+is_empty = False
 return rows
 
 def as_sql(self):

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 05:35:10 UTC (rev 9968)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/model_inheritance_regress/models.py
2009-03-04 05:40:22 UTC (rev 9969)
@@ -271,8 +271,8 @@
 # (regression test for #10362).
 >>> article = ArticleWithAuthor.objects.create(author="fred", headline="Hey 
 >>> there!", pub_date = datetime.datetime(2009, 3, 1, 8, 0, 0))
 >>> ArticleWithAuthor.objects.filter(author="fred").update(headline="Oh, no!")
-0
+1
 >>> ArticleWithAuthor.objects.filter(pk=article.pk).update(headline="Oh, no!")
-0
+1
 
 """}


--~--~-~--~~~---~--~~
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] r9967 - in django/trunk: django/db/models/sql tests/regressiontests/model_inheritance_regress

[noreply]

Author: mtredinnick
Date: 2009-03-03 23:34:01 -0600 (Tue, 03 Mar 2009)
New Revision: 9967

Modified:
   django/trunk/django/db/models/sql/query.py
   django/trunk/django/db/models/sql/subqueries.py
   django/trunk/tests/regressiontests/model_inheritance_regress/models.py
Log:
Fixed #10362 -- An update() that only affects a parent model no longer crashes.

This includes a fairly large refactor of the update() query path (and
the initial portions of constructing the SQL for any query). The
previous code appears to have been only working more or less by accident
and was very fragile.

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2009-03-04 05:33:23 UTC (rev 
9966)
+++ django/trunk/django/db/models/sql/query.py  2009-03-04 05:34:01 UTC (rev 
9967)
@@ -62,6 +62,7 @@
 self.dupe_avoidance = {}
 self.used_aliases = set()
 self.filter_is_sticky = False
+self.included_inherited_models = {}
 
 # SQL-related attributes
 self.select = []
@@ -171,6 +172,7 @@
 obj.default_cols = self.default_cols
 obj.default_ordering = self.default_ordering
 obj.standard_ordering = self.standard_ordering
+obj.included_inherited_models = self.included_inherited_models.copy()
 obj.ordering_aliases = []
 obj.select_fields = self.select_fields[:]
 obj.related_select_fields = self.related_select_fields[:]
@@ -304,6 +306,7 @@
 self.select = []
 self.default_cols = False
 self.extra_select = {}
+self.remove_inherited_models()
 
 query.clear_ordering(True)
 query.clear_limits()
@@ -458,6 +461,7 @@
 assert self.distinct == rhs.distinct, \
 "Cannot combine a unique query with a non-unique query."
 
+self.remove_inherited_models()
 # Work out how to relabel the rhs aliases, if necessary.
 change_map = {}
 used = set()
@@ -540,6 +544,9 @@
 """
 if not self.tables:
 self.join((None, self.model._meta.db_table, None, None))
+if (not self.select and self.default_cols and not
+self.included_inherited_models):
+self.setup_inherited_models()
 if self.select_related and not self.related_select_cols:
 self.fill_related_selections()
 
@@ -619,7 +626,9 @@
 start_alias=None, opts=None, as_pairs=False):
 """
 Computes the default columns for selecting every field in the base
-model.
+model. Will sometimes be called to pull in related models (e.g. via
+select_related), in which case "opts" and "start_alias" will be given
+to provide a starting point for the traversal.
 
 Returns a list of strings, quoted appropriately for use in SQL
 directly, as well as a set of aliases used in the select statement (if
@@ -629,22 +638,25 @@
 result = []
 if opts is None:
 opts = self.model._meta
-if start_alias:
-table_alias = start_alias
-else:
-table_alias = self.tables[0]
-root_pk = opts.pk.column
-seen = {None: table_alias}
 qn = self.quote_name_unless_alias
 qn2 = self.connection.ops.quote_name
 aliases = set()
+if start_alias:
+seen = {None: start_alias}
+root_pk = opts.pk.column
 for field, model in opts.get_fields_with_model():
-try:
-alias = seen[model]
-except KeyError:
-alias = self.join((table_alias, model._meta.db_table,
-root_pk, model._meta.pk.column))
-seen[model] = alias
+if start_alias:
+try:
+alias = seen[model]
+except KeyError:
+alias = self.join((start_alias, model._meta.db_table,
+root_pk, model._meta.pk.column))
+seen[model] = alias
+else:
+# If we're starting from the base model of the queryset, the
+# aliases will have already been set up in pre_sql_setup(), so
+# we can save time here.
+alias = self.included_inherited_models[model]
 if as_pairs:
 result.append((alias, field.column))
 continue
@@ -996,6 +1008,9 @@
 if alias == old_alias:
 self.tables[pos] = new_alias
 break
+for key, alias in self.included_inherited_models.items():
+if alias in change_map:
+self.included_inherited_models[key] = change_map[alias]
 
 # 3. Update any joins that refer to the old alias.
 for alias, data in self.alias_map.iteritems():
@@ -1062,9 +1077,11 @@
 lhs.lhs_col = 

[Changeset] r9966 - django/trunk/django/db/models/sql

[noreply]

Author: mtredinnick
Date: 2009-03-03 23:33:23 -0600 (Tue, 03 Mar 2009)
New Revision: 9966

Modified:
   django/trunk/django/db/models/sql/subqueries.py
Log:
Changed the row count value returned from update queries in some cases.

If an update only affected an ancestor model (not the child), we were
returning 0 for the number of rows updated. This could have been
misleading if the value is used to detect an update occuring. So we now
return the rowcount from the first non-trivial query that is executed
(if any). Still a slight compromise, but better than what we had.

Modified: django/trunk/django/db/models/sql/subqueries.py
===
--- django/trunk/django/db/models/sql/subqueries.py 2009-03-04 04:56:20 UTC 
(rev 9965)
+++ django/trunk/django/db/models/sql/subqueries.py 2009-03-04 05:33:23 UTC 
(rev 9966)
@@ -113,14 +113,19 @@
 def execute_sql(self, result_type=None):
 """
 Execute the specified update. Returns the number of rows affected by
-the primary update query (there could be other updates on related
-tables, but their rowcounts are not returned).
+the primary update query. The "primary update query" is the first
+non-empty query that is executed. Row counts for any subsequent,
+related queries are not available.
 """
 cursor = super(UpdateQuery, self).execute_sql(result_type)
 rows = cursor and cursor.rowcount or 0
+is_empty = cursor is None
 del cursor
 for query in self.get_related_updates():
-query.execute_sql(result_type)
+aux_rows = query.execute_sql(result_type)
+if is_empty:
+rows = aux_rows
+is_empty = False
 return rows
 
 def as_sql(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-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] #9696: FileField raises unhandled exception when filename contains non-ascii characters

[Django]

#9696: FileField raises unhandled exception when filename contains non-ascii
characters
---+
  Reporter:  magarac   | Owner:  nobody
Status:  reopened  | Milestone:  1.1   
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by liangent):

 * cc: liang...@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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by liangent):

 Replying to [comment:40 ikelly]:
 > I've found the problem -- turns out it has nothing to do with Oracle.
 It's [http://bugs.python.org/issue1868 Python bug 1868] combined with
 setting {{{DEBUG=True}}} in the settings file; I had that set in my oracle
 test settings file, but not in my postgres or mysql files.  With
 {{{DEBUG=True}}} set, the cursor gets wrapped in a
 {{{CursorDebugWrapper}}}, which has a {{{finally}}} clause in its
 {{{execute}}} method that accesses an attribute of the
 {{{ConnectionWrapper}}} object, triggering the bug.
 >
 > I don't think this is likely to be a major issue outside of the test
 suite, so I wouldn't object to moving the rollback in
 {{{handle_deadlock}}} back to its original location, as long as we do
 something in the test to make sure it doesn't hang.
 >
 > Also, I think {{{select_for_update}}} is the wrong place to set the
 transaction dirty.  That needs to happen when the query is run, not when
 the queryset is constructed, which is not necessarily the same time.

 anyhow, transaction should be set dirty after SELECT FOR UPDATE was
 executed.

-- 
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] r9965 - django/trunk/django/db/models/fields

[noreply]

Author: mtredinnick
Date: 2009-03-03 22:56:20 -0600 (Tue, 03 Mar 2009)
New Revision: 9965

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/django/db/models/fields/related.py
Log:
Changed the handling of as_sql() versus _as_sql() in Query/QuerySet from r9928.

This avoids inadvertently hiding AttributeError that is raised for other
reasons.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2009-03-04 04:53:15 UTC 
(rev 9964)
+++ django/trunk/django/db/models/fields/__init__.py2009-03-04 04:56:20 UTC 
(rev 9965)
@@ -198,9 +198,9 @@
 # be invoked before the final SQL is evaluated
 if hasattr(value, 'relabel_aliases'):
 return value
-try:
+if hasattr(value, 'as_sql'):
 sql, params = value.as_sql()
-except AttributeError:
+else:
 sql, params = value._as_sql()
 return QueryWrapper(('(%s)' % sql), params)
 

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2009-03-04 04:53:15 UTC 
(rev 9964)
+++ django/trunk/django/db/models/fields/related.py 2009-03-04 04:56:20 UTC 
(rev 9965)
@@ -145,9 +145,9 @@
 # be invoked before the final SQL is evaluated
 if hasattr(value, 'relabel_aliases'):
 return value
-try:
+if hasattr(value, 'as_sql'):
 sql, params = value.as_sql()
-except AttributeError:
+else:
 sql, params = value._as_sql()
 return QueryWrapper(('(%s)' % sql), params)
 


--~--~-~--~~~---~--~~
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] r9964 - django/trunk/django/core/management/commands

[noreply]

Author: mtredinnick
Date: 2009-03-03 22:53:15 -0600 (Tue, 03 Mar 2009)
New Revision: 9964

Modified:
   django/trunk/django/core/management/commands/dumpdata.py
Log:
Fixed #10381 -- Fixed some a machine-dependent test failure after r9921.

The patch is from Russell, but I'm applying it because I want my tests to pass
again (and he doesn't see the failure).

Modified: django/trunk/django/core/management/commands/dumpdata.py
===
--- django/trunk/django/core/management/commands/dumpdata.py2009-03-03 
22:10:15 UTC (rev 9963)
+++ django/trunk/django/core/management/commands/dumpdata.py2009-03-04 
04:53:15 UTC (rev 9964)
@@ -1,6 +1,7 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.core.management.base import BaseCommand, CommandError
 from django.core import serializers
+from django.utils.datastructures import SortedDict
 
 from optparse import make_option
 
@@ -27,9 +28,9 @@
 excluded_apps = [get_app(app_label) for app_label in exclude]
 
 if len(app_labels) == 0:
-app_list = dict([(app, None) for app in get_apps() if app not in 
excluded_apps])
+app_list = SortedDict([(app, None) for app in get_apps() if app 
not in excluded_apps])
 else:
-app_list = {}
+app_list = SortedDict()
 for label in app_labels:
 try:
 app_label, model_label = label.split('.')


--~--~-~--~~~---~--~~
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] #6674: Missing widget documentation

[Django]

#6674: Missing widget documentation
+---
  Reporter:  Karen Tracey   | Owner:  
holdenweb
Status:  new| Milestone:
   
 Component:  Documentation  |   Version:  SVN   
   
Resolution: |  Keywords:
   
 Stage:  Accepted   | Has_patch:  0 
   
Needs_docs:  1  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 #10407 asked for render_value doc also.

-- 
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] #10407: PasswordInput's render_value argument should be documented

[Django]

#10407: PasswordInput's render_value argument should be documented
+---
  Reporter:  collink| Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 Isn't this the same as #6674?

-- 
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] #10408: Invalid date in DB results in "ValueError: year is out of range" in admin view when using date_hierarchy

[Django]

#10408: Invalid date in DB results in "ValueError: year is out of range" in 
admin
view when using date_hierarchy
+---
 Reporter:  iammichael  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.0   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I have a legacy MySQL database that I'm trying to build a django
 application around.  When using a date_hierarcy in the admin interface, I
 receive a !ValueError when rendering the list of objects (full traceback
 in the test case, below).  This is caused by dates in the database that
 contain an invalid year ('').  The issue is similar to ticket:6642,
 but the problem is exhibited in the admin interface without any use of
 fixtures, dumpdata, or loaddata.  The root underlying cause, and thus the
 fix, may be the same for both, although the current patch in ticket:6642
 updates only typecast_date and the error I am receiving is in
 typecast_timestamp.  The issue described here seems like it may be a
 little more common of an issue than the one described in ticket:6642.


 Test case:

 Create a "legacy" mysql database using the mysql test case script
 [http://code.djangoproject.com/attachment/ticket/6642/test_case.mysql.sql
 attached to 6642].

 Setup the following model in models.py:
 {{{
 from django.db import models
 class Testcase(models.Model):
 id = models.IntegerField(primary_key=True, unique=True,
 db_column='ID')
 date = models.DateField(db_column='Date')
 header = models.CharField(max_length=150, db_column='Header')
 class Meta:
 db_table = u'TestCase'
 }}}

 Enable the admin interface and add the following to admin.py
 {{{
 from django.contrib import admin
 from models import Testcase

 class TestcaseAdmin(admin.ModelAdmin):
 list_display = ('id', 'date', 'header')
 date_hierarchy = 'date'
 admin.site.register(Testcase, TestcaseAdmin)
 }}}

 Now, try to view the Testcase data in the admin interface.  The processing
 of the date_hierarchy causes the following error:
 {{{
 TemplateSyntaxError at /admin/testcase/testcase/

 Caught an exception while rendering: year is out of range

 Original Traceback (most recent call last):
   File "/usr/lib/python2.4/site-packages/django/template/debug.py", line
 71, in render_node
 result = node.render(context)
   File "/usr/lib/python2.4/site-packages/django/template/__init__.py",
 line 916, in render
 dict = func(*args)
   File "/usr/lib/python2.4/site-
 packages/django/contrib/admin/templatetags/admin_list.py", line 294, in
 date_hierarchy
 return {
   File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line
 186, in _result_iter
 self._fill_cache()
   File "/usr/lib/python2.4/site-packages/django/db/models/query.py", line
 667, in _fill_cache
 self._result_cache.append(self._iter.next())
   File "/usr/lib/python2.4/site-
 packages/django/db/models/sql/subqueries.py", line 384, in results_iter
 date = typecast_timestamp(str(date))
   File "/usr/lib/python2.4/site-packages/django/db/backends/util.py", line
 88, in typecast_timestamp
 int(times[0]), int(times[1]), int(seconds),
 int(float('.'+microseconds) * 100))
 ValueError: year is out of range
 }}}

-- 
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] #10407: PasswordInput's render_value argument should be documented

[Django]

#10407: PasswordInput's render_value argument should be documented
+---
  Reporter:  collink| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * summary:  Documentation needed for Form Values => PasswordInput's
  render_value argument should be documented
  * stage:  Unreviewed => Accepted

Comment:

 It's a common IRC FAQ.

 More than just the example given in the description, it should primarily
 document that the `PasswordInput` class can be called like
 `PasswordInput(render_value=False)` to achieve this same behaviour

-- 
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] #10407: Documentation needed for Form Values

[Django]

#10407: Documentation needed for Form Values
+---
  Reporter:  collink| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by collink):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Documentation
  * needs_tests:  => 0
  * 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] #10407: Documentation needed for Form Values

[Django]

#10407: Documentation needed for Form Values
---+
 Reporter:  collink|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 For example:

 form = LoginForm( request.POST )
 if not form.is_valid( ):
 form.fields['password'].widget.render_value = False

-- 
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] #10406: Primary keys with model inheritance problems.

[Django]

#10406: Primary keys with model inheritance problems.
---+
  Reporter:  ramiro| Owner:  
mtredinnick  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
parent_link primary_key onetoonefield
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * summary:  Inconsistent handling of primary key flag between implicit
  and explicit (parent_link=True) model
  inheritance o2o fields when another explicit PK
  field is also used => Primary keys with model
  inheritance problems.

Comment:

 Relax. This doesn't need another ticket (and the paragraph-long title
 isn't really making things clearer at a glance. :-))

 We're just messing up the pk assignment in some cases. It's the same root
 cause as #10251. #7367 is an old ticket (pre-queryset-refactor) and one-
 to-one fields no longer need to be primary keys, since otherwise multiple
 inheritance wouldn't be possible.

-- 
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] #10390: "exact" should be NULL-safe comparison

[Django]

#10390: "exact" should be NULL-safe comparison
---+
  Reporter:  tallfred  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 This makes sense to me.  We already allow {{{foo__exact=None}}}, which is
 silently converted to {{{foo__isnull=True}}}.  One might naively expect to
 be able to do {{{.filter(foo__exact=F('foo'))}}} and have it effectively
 be a no-op like {{{.all()}}} (obviously this example is useless, but I'm
 sure a more reasonable use case could be devised).  But the {{{IS NULL}}}
 conversion doesn't happen in that case, and all the nulls would be
 filtered out.  The proposed patch would fix this.

 I'm fairly sure that {{{<=>}}} isn't standard SQL.  The PostgreSQL
 equivalent would be {{{IS NOT DISTINCT FROM}}}.  The canonical Oracle
 implementation is {{{DECODE(column, %s, 1) = 1}}}.  I have no idea what
 SQLite uses.

-- 
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] #10406: Explicit PK plus explicit multi-table inheritance parent link o2o field result in two primary keys

[Django]

#10406: Explicit PK plus explicit multi-table inheritance parent link o2o field
result in two primary keys
---+
 Reporter:  ramiro |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Database layer (models, ORM)   | Version:  SVN   
 Keywords:  parent_link primary_key onetoonefield  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 With this model setup:

 {{{
 #!python
 from django.db import models

 class Persona(models.Model):
 nombre = models.CharField(max_length=60)

 class Cliente(Persona):
 cli_id = models.AutoField(primary_key=True)
 persona = models.OneToOneField(Persona, parent_link=True)
 }}}

 `sqlall` output (with SQLite, MySQL shows the same) shows that the two
 Client fields are declared `PRIMARY KEY`:

 {{{
 #!sql
 CREATE TABLE "thread1_persona" (
 "id" integer NOT NULL PRIMARY KEY,
 "nombre" varchar(60) NOT NULL
 )
 ;
 CREATE TABLE "thread1_cliente" (
 "cli_id" integer NOT NULL PRIMARY KEY,
 "persona_id" integer NOT NULL PRIMARY KEY REFERENCES "thread1_persona"
 ("id")
 )
 ;
 COMMIT;
 }}}

 Problem also show if the explicit Cliente PK is changed from AutoField to
 another field type.

 Commenting out
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/base.py#L101
 solves the problem (and Django test suite still passes):

 {{{
 #!sql
 BEGIN;
 CREATE TABLE "thread1_persona" (
 "id" integer NOT NULL PRIMARY KEY,
 "nombre" varchar(60) NOT NULL
 )
 ;
 CREATE TABLE "thread1_cliente" (
 "cli_id" integer NOT NULL PRIMARY KEY,
 "persona_id" integer NOT NULL UNIQUE REFERENCES "thread1_persona"
 ("id")
 )
 ;
 COMMIT;
 }}}

 If Cliente is changed to inherit from models.Model, problem also goes
 away.

 This issue could be related to #10251, but the example posted there
 doesn't show this double PK problem because it isn't using an explicit
 OneToOneField with parent_link for the inheritance.

-- 
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] #9054: request.raw_post_data is empty for multipart/related posts

[Django]

#9054: request.raw_post_data is empty for multipart/related posts
+---
  Reporter:  gruffudd   | Owner:  nobody   
Status:  new| Milestone:   
 Component:  HTTP handling  |   Version:  1.0  
Resolution: |  Keywords:  multipart
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by Uninen):

 * cc: vi...@syneus.fi (added)

Comment:

 This is possibly related to #3211.

-- 
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] #10188: HttpResponse does not filter CR/LF characters from headers

[Django]

#10188: HttpResponse does not filter CR/LF characters from headers
+---
  Reporter:  bthomas| Owner:  rokclimb15
Status:  new| Milestone:  1.1   
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Comment (by rokclimb15):

 I have installed this patch on my production web server running many
 sites.  No hiccups or 500 emails so far.  Working on a couple of unit
 tests for this patch.

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

[Changeset] r9963 - in django/trunk/django/contrib/gis: db/models/sql tests tests/relatedapp

[noreply]

Author: jbronn
Date: 2009-03-03 16:10:15 -0600 (Tue, 03 Mar 2009)
New Revision: 9963

Modified:
   django/trunk/django/contrib/gis/db/models/sql/query.py
   django/trunk/django/contrib/gis/db/models/sql/where.py
   django/trunk/django/contrib/gis/tests/__init__.py
   django/trunk/django/contrib/gis/tests/relatedapp/models.py
   django/trunk/django/contrib/gis/tests/relatedapp/tests.py
Log:
Fixed #10159 -- `F()` expressions now work on geographic fields.  The tests are 
in `relatedapp`, which has been retrofitted to work with Oracle (minus the 
prior offending tests).  I'm back.


Modified: django/trunk/django/contrib/gis/db/models/sql/query.py
===
--- django/trunk/django/contrib/gis/db/models/sql/query.py  2009-03-03 
02:50:23 UTC (rev 9962)
+++ django/trunk/django/contrib/gis/db/models/sql/query.py  2009-03-03 
22:10:15 UTC (rev 9963)
@@ -278,40 +278,6 @@
 return sel_fmt
 
 # Private API utilities, subject to change.
-def _check_geo_field(self, model, name_param):
-"""
-Recursive utility routine for checking the given name parameter
-on the given model.  Initially, the name parameter is a string,
-of the field on the given model e.g., 'point', 'the_geom'.
-Related model field strings like 'address__point', may also be
-used.
-
-If a GeometryField exists according to the given name parameter
-it will be returned, otherwise returns False.
-"""
-if isinstance(name_param, basestring):
-# This takes into account the situation where the name is a
-# lookup to a related geographic field, e.g., 'address__point'.
-name_param = name_param.split(sql.constants.LOOKUP_SEP)
-name_param.reverse() # Reversing so list operates like a queue of 
related lookups.
-elif not isinstance(name_param, list):
-raise TypeError
-try:
-# Getting the name of the field for the model (by popping the first
-# name from the `name_param` list created above).
-fld, mod, direct, m2m = 
model._meta.get_field_by_name(name_param.pop())
-except (FieldDoesNotExist, IndexError):
-return False
-# TODO: ManyToManyField?
-if isinstance(fld, GeometryField):
-return fld # A-OK.
-elif isinstance(fld, ForeignKey):
-# ForeignKey encountered, return the output of this utility called
-# on the _related_ model with the remaining name parameters.
-return self._check_geo_field(fld.rel.to, name_param) # Recurse to 
check ForeignKey relation.
-else:
-return False
-
 def _field_column(self, field, table_alias=None):
 """
 Helper function that returns the database column for the given field.
@@ -339,4 +305,4 @@
 else:
 # Otherwise, check by the given field name -- which may be
 # a lookup to a _related_ geographic field.
-return self._check_geo_field(self.model, field_name)
+return GeoWhereNode._check_geo_field(self.model._meta, field_name)

Modified: django/trunk/django/contrib/gis/db/models/sql/where.py
===
--- django/trunk/django/contrib/gis/db/models/sql/where.py  2009-03-03 
02:50:23 UTC (rev 9962)
+++ django/trunk/django/contrib/gis/db/models/sql/where.py  2009-03-03 
22:10:15 UTC (rev 9963)
@@ -1,7 +1,11 @@
-import datetime
+from django.db import connection
 from django.db.models.fields import Field
+from django.db.models.sql.constants import LOOKUP_SEP
+from django.db.models.sql.expressions import SQLEvaluator
 from django.db.models.sql.where import WhereNode
 from django.contrib.gis.db.backend import get_geo_where_clause, SpatialBackend
+from django.contrib.gis.db.models.fields import GeometryField
+qn = connection.ops.quote_name
 
 class GeoAnnotation(object):
 """
@@ -37,10 +41,36 @@
 # Not a geographic field, so call `WhereNode.add`.
 return super(GeoWhereNode, self).add(data, connector)
 else:
-# `GeometryField.get_db_prep_lookup` returns a where clause
-# substitution array in addition to the parameters.
-where, params = field.get_db_prep_lookup(lookup_type, value)
+if isinstance(value, SQLEvaluator):
+# Getting the geographic field to compare with from the 
expression.
+geo_fld = self._check_geo_field(value.opts, 
value.expression.name)
+if not geo_fld:
+raise ValueError('No geographic field found in 
expression.')
 
+# Get the SRID of the geometry field that the expression was 
meant 
+# to operate on -- it's needed to determine whether 
transformation 
+# SQL is necessary.
+srid = geo_fld._srid
+
+

Re: [Django] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
+---
  Reporter:  danbrwn| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0-alpha-2   
Resolution: |  Keywords:  foreign,key,quoted
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Replying to [comment:1 Alex]:
 > Pleas use the preview button.  Further this is tested quite extensively:
 
http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/string_lookup/models.py
 so if no more details can be provided I'm going to mark worksforme.

 Notice two people have reported this recently on django-users, both (I
 believe) mentioned they saw the problem only under mod_python/Apache, and
 not the development server, so there is something different about non-dev-
 server environment.  I'm not sure the test environment can be used to
 completely mimic what's happening under Apache here.  I could wish for a
 more minimal failing example, but before closing worksforme I think
 something like this needs to be tested under mod_python (or mod_wsgi), not
 just under dev server.  I myself won't be able to do that for a few days
 yet, as I'm away from home and my test machines.  If someone else does do
 that please post the minimal (failing or working) example of FK reference
 using quoted strings.

 Replying to [comment:2 ramiro]:
 > See also #8569

 One of the posters who ran into this on the user's list did find that
 ticket also.  The fix for that went in before 1.0 so I believe both
 posters already have it.  That fix happens to only be relevant when DEBUG
 is set to True: the traceback there was from the admin validation routine
 which is only called when DEBUG is on, and the fix that went in also
 applies only when DEBUG is on.  At least one of the posters who ran into
 this recently specifically noted it only happened with DEBUG=False, and
 under Apache, not the dev server.

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by ikelly):

 I've found the problem -- turns out it has nothing to do with Oracle.
 It's [http://bugs.python.org/issue1868 Python bug 1868] combined with
 setting {{{DEBUG=True}}} in the settings file; I had that set in my oracle
 test settings file, but not in my postgres or mysql files.  With
 {{{DEBUG=True}}} set, the cursor gets wrapped in a
 {{{CursorDebugWrapper}}}, which has a {{{finally}}} clause in its
 {{{execute}}} method that accesses an attribute of the
 {{{ConnectionWrapper}}} object, triggering the bug.

 I don't think this is likely to be a major issue outside of the test
 suite, so I wouldn't object to moving the rollback in
 {{{handle_deadlock}}} back to its original location, as long as we do
 something in the test to make sure it doesn't hang.

 Also, I think {{{select_for_update}}} is the wrong place to set the
 transaction dirty.  That needs to happen when the query is run, not when
 the queryset is constructed, which is not necessarily the same time.

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

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

[Django]

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

 Oh hey, just uploaded the same patch again, that was smart.

-- 
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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
+---
  Reporter:  danbrwn| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0-alpha-2   
Resolution: |  Keywords:  foreign,key,quoted
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by ramiro):

 See also #8569

-- 
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] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
+---
  Reporter:  danbrwn| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0-alpha-2   
Resolution: |  Keywords:  foreign,key,quoted
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Old description:

> Myself and another discovered the following error with the code shown. In
> both cases we had quoted strings for reference class. In both cases
> importing the specific class and then referencing without the quotes
> solved the problem. I tried through IRC channel to get a resolution.
> Downloaded code, wiped out site-packages/django dir before running setup,
> took other suggestions. Nothing worked except removing the quotes as
> suggested on the django-users group. I am running Debian Etch final.
> Python 2.5 and Django 1.0.2, Apache2 with mod_python
> AttributeError: 'str' object has no attribute '_default_manager
> -- getting this error
> --
> MOD_PYTHON ERROR
>
> ProcessId:  2637
> Interpreter:'TS1.unassigned-domain'
>
> ServerName: 'TS1.unassigned-domain'
> DocumentRoot:   '/var/www/'
>
> URI:'/sipprovision/admin'
> Location:   '/sipprovision/'
> Directory:  None
> Filename:   '/var/www/sipprovision/admin'
> PathInfo:   ''
>
> Phase:  'PythonHandler'
> Handler:'django.core.handlers.modpython'
>
> Traceback (most recent call last):
>
>   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
> 1537, in HandlerDispatch
> default=default_handler, arg=req, silent=hlist.silent)
>
>   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
> 1229, in _process_target
> result = _execute_target(config, req, object, arg)
>
>   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
> 1128, in _execute_target
> result = object(arg)
>
>   File "/usr/lib/python2.5/site-
> packages/django/core/handlers/modpython.py", line 228, in handler
> return ModPythonHandler()(req)
>
>   File "/usr/lib/python2.5/site-
> packages/django/core/handlers/modpython.py", line 201, in __call__
> response = self.get_response(request)
>
>   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py",
> line 67, in get_response
> response = middleware_method(request)
>
>   File "/usr/lib/python2.5/site-packages/django/middleware/common.py",
> line 56, in process_request
> if (not _is_valid_path(request.path_info) and
>
>   File "/usr/lib/python2.5/site-packages/django/middleware/common.py",
> line 142, in _is_valid_path
> urlresolvers.resolve(path)
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 246, in resolve
> return get_resolver(urlconf).resolve(path)
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 179, in resolve
> for pattern in self.urlconf_module.urlpatterns:
>
>   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
> line 198, in _get_urlconf_module
> self._urlconf_module = __import__(self.urlconf_name, {}, {}, [''])
>
>   File "/var/www/sipprovision/urls.py", line 2, in 
> from extensions.models import Extension
>
>   File "/var/www/sipprovision/extensions/models.py", line 42, in 
> class ExtensionForm(ModelForm):
>
>   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
> 195, in __new__
> opts.exclude, formfield_callback)
>
>   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
> 162, in fields_for_model
> formfield = formfield_callback(f)
>
>   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
> 177, in 
> lambda f: f.formfield())
>
>   File "/usr/lib/python2.5/site-
> packages/django/db/models/fields/related.py", line 694, in formfield
> 'queryset': self.rel.to._default_manager.complex_filter(
>
> AttributeError: 'str' object has no attribute '_default_manager'
>

> - with this model
> -
> from django.db import models
> from sipconfig import *
> from django.forms import ModelForm, fields, TextInput, IntegerField
> # Create your models here.
> class Plc(models.Model):
> name=models.CharField(max_length=30)
> ip_addr=models.IPAddressField()
> ip_port=models.IntegerField(default=9600)
> plc_net=models.IntegerField()
> 

[Django] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
+---
 Reporter:  danbrwn |   Owner:  nobody 
   Status:  new |   Milestone: 
Component:  Uncategorized   | Version:  1.0-alpha-2
 Keywords:  foreign,key,quoted  |   Stage:  Unreviewed 
Has_patch:  0   |  
+---
 Myself and another discovered the following error with the code shown. In
 both cases we had quoted strings for reference class. In both cases
 importing the specific class and then referencing without the quotes
 solved the problem. I tried through IRC channel to get a resolution.
 Downloaded code, wiped out site-packages/django dir before running setup,
 took other suggestions. Nothing worked except removing the quotes as
 suggested on the django-users group. I am running Debian Etch final.
 Python 2.5 and Django 1.0.2, Apache2 with mod_python
 AttributeError: 'str' object has no attribute '_default_manager
 -- getting this error
 --
 MOD_PYTHON ERROR

 ProcessId:  2637
 Interpreter:'TS1.unassigned-domain'

 ServerName: 'TS1.unassigned-domain'
 DocumentRoot:   '/var/www/'

 URI:'/sipprovision/admin'
 Location:   '/sipprovision/'
 Directory:  None
 Filename:   '/var/www/sipprovision/admin'
 PathInfo:   ''

 Phase:  'PythonHandler'
 Handler:'django.core.handlers.modpython'

 Traceback (most recent call last):

   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
 1537, in HandlerDispatch
 default=default_handler, arg=req, silent=hlist.silent)

   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
 1229, in _process_target
 result = _execute_target(config, req, object, arg)

   File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line
 1128, in _execute_target
 result = object(arg)

   File "/usr/lib/python2.5/site-
 packages/django/core/handlers/modpython.py", line 228, in handler
 return ModPythonHandler()(req)

   File "/usr/lib/python2.5/site-
 packages/django/core/handlers/modpython.py", line 201, in __call__
 response = self.get_response(request)

   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py",
 line 67, in get_response
 response = middleware_method(request)

   File "/usr/lib/python2.5/site-packages/django/middleware/common.py",
 line 56, in process_request
 if (not _is_valid_path(request.path_info) and

   File "/usr/lib/python2.5/site-packages/django/middleware/common.py",
 line 142, in _is_valid_path
 urlresolvers.resolve(path)

   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
 line 246, in resolve
 return get_resolver(urlconf).resolve(path)

   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
 line 179, in resolve
 for pattern in self.urlconf_module.urlpatterns:

   File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py",
 line 198, in _get_urlconf_module
 self._urlconf_module = __import__(self.urlconf_name, {}, {}, [''])

   File "/var/www/sipprovision/urls.py", line 2, in 
 from extensions.models import Extension

   File "/var/www/sipprovision/extensions/models.py", line 42, in 
 class ExtensionForm(ModelForm):

   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
 195, in __new__
 opts.exclude, formfield_callback)

   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
 162, in fields_for_model
 formfield = formfield_callback(f)

   File "/usr/lib/python2.5/site-packages/django/forms/models.py", line
 177, in 
 lambda f: f.formfield())

   File "/usr/lib/python2.5/site-
 packages/django/db/models/fields/related.py", line 694, in formfield
 'queryset': self.rel.to._default_manager.complex_filter(

 AttributeError: 'str' object has no attribute '_default_manager'


 - with this model
 -
 from django.db import models
 from sipconfig import *
 from django.forms import ModelForm, fields, TextInput, IntegerField
 # Create your models here.
 class Plc(models.Model):
 name=models.CharField(max_length=30)
 ip_addr=models.IPAddressField()
 ip_port=models.IntegerField(default=9600)
 plc_net=models.IntegerField()
 plc_node=models.IntegerField()
 plc_unit=models.IntegerField()

 def __unicode__(self):
   return self.name

 class Admin: pass

 class VoipGateway(models.Model):
 name=models.OneToOneField('sipconfig.station')
 def __unicode__(self):
   return self.name.dev_name
 class Admin: pass

 class Extension(models.Model):
 PREFIX_CHOICE=(
 ('1','station'),
 ('9','lock'),
 

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anih):

 Replying to [comment:38 ikelly]:
 > Update: I'm having a heck of a time nailing down exactly what's going on
 with this hang issue.  It reliably occurs when using the oracle backend,
 but outside of Django I can't reproduce it at all; the connection does get
 properly cleaned up when the deadlocked thread exits.  About the only
 thing I've managed to determine is that if I run {{{del
 connection.connection}}} when exiting the test threads, then the issue
 does not occur and the tests pass.  What I can't figure out is why this is
 necessary.

 maybe problem is related with that select_for_update didnt set transaction
 dirty? new patch have this corected(i think)

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

[Django] #10404: ImageField: height_field and width_field option sometimes doesn't work

[Django]

#10404: ImageField: height_field and width_field option sometimes doesn't work
---+
 Reporter:  Lehich |   Owner:  nobody
   Status:  new|   Milestone:
Component:  File uploads/storage   | Version:  SVN   
 Keywords:  ImageField, height_field, width_field  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I had a problem: height_field and width_field always = 0 in some models,
 after uploading any image file.
 Problem was in fields order: if height_field and width_field goes before
 image field - this thing happends.

 I appears in models save method.
 /django/db/models/base.py : 378 (actual for revision: 9962)

 {{{
 values = [(f, None, f.get_db_prep_save(raw and getattr(self, f.attname) or
 f.pre_save(self, False))) for f in non_pks]
 }}}

 here all fields values are calculated (''get_db_prep_save'') and copy to
 ''values''. So, if in models description ImageField goes before height and
 width fields, everything is fine. But if ImageField goes after this
 fields, all pic size calculation still in fields but not in values list.

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

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by ikelly):

 Replying to [comment:33 ikelly]:
 > I made a small change to handle_deadlocks so that the transaction is
 automatically rolled back when a deadlock is detected and no retries are
 left.  The reason for this is that in Oracle, the second thread in the
 test was still waiting for the first thread to rollback even after the
 first thread had been joined and presumably had its resources cleaned up.
 The alternative would be to leave it as is and recommend the user to
 always rollback whenever a DeadlockError is raised, but I'm not thrilled
 with that: one might expect to be able to ignore the DeadlockError and
 have the deadlock be fully resolved.
 >
 > I'll also be checking on the cx_Oracle mailing list whether this
 behavior is intended.

 Update: I'm having a heck of a time nailing down exactly what's going on
 with this hang issue.  It reliably occurs when using the oracle backend,
 but outside of Django I can't reproduce it at all; the connection does get
 properly cleaned up when the deadlocked thread exits.  About the only
 thing I've managed to determine is that if I run {{{del
 connection.connection}}} when exiting the test threads, then the issue
 does not occur and the tests pass.  What I can't figure out is why this is
 necessary.

-- 
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] #10403: provide declarative syntax to define ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define ModelFormSet and InlineFormSet
--+-
 Reporter:  Koen Biermans   |   Owner:  
nobody
   Status:  new   |   Milestone:

Component:  Forms | Version:  SVN   

 Keywords:  modelformset inlineformset|   Stage:  
Unreviewed
Has_patch:  1 |  
--+-
 Provide a declarative mechanism to define modelformsets or inlineformsets.

 The attached patch allows definitions like this:

 {{{
 class AuthorForm(forms.ModelForm):
 class Meta:
 model = Author

 class DeclarativeAuthorFormSet(forms.models.ModelFormSet):
 form = AuthorForm
 model = Author
 extra = 3
 }}}

 and

 {{{
 class BookForm(forms.ModelForm):
 class Meta:
 model = Book

 class DeclarativeAuthorBooksFormSet(forms.models.InlineFormSet):
 model = Book
 form = BookForm
 parent = 'author'

 }}}

 An advantage is that the defined form is directly used as the form class
 in the formset, not as a base class for a new form class (what
 inlineformset_factory does). This way specific field definitions and other
 customisations in the form work like they should so you don't need to
 redefine things in __init__().

-- 
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] #10263: order_by parameter for inlineformset_factory and BaseInlineFormSet

[Django]

#10263: order_by parameter for inlineformset_factory and BaseInlineFormSet
-+--
  Reporter:  Paulo Scardine   | Owner:  
nobody  
Status:  new | Milestone:   
   
 Component:  Forms   |   Version:  
1.0 
Resolution:  |  Keywords:  
inlineformset_factory BaseInlineFormSet inline model formset
 Stage:  Design decision needed  | Has_patch:  
1   
Needs_docs:  0   |   Needs_tests:  
0   
Needs_better_patch:  0   |  
-+--
Comment (by paulos):

 New patch adds a queryset argument to BaseInlineFormSet making it
 consistent with BaseModelFormset, as sugested by Alex.

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

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

[Django]

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

 * cc: h...@tbz-pariv.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-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] #10401: Very long URL cause django error.

[Django]

#10401: Very long URL cause django error.
+---
  Reporter:  bigmonkey.bigmon...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:  handler404
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by bigmonkey.bigmon...@gmail.com):

 Oh, I am sorry to take a duplicate ticket.

-- 
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] #10400: File upload documentation should emphasize the need to add multipart/form-data

[Django]

#10400: File upload documentation should emphasize the need to add 
multipart/form-
data
+---
  Reporter:  claudep| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Unreviewed => Accepted

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

[Django] #10402: mysql backend connections left idle open

[Django]

#10402: mysql backend connections left idle open
--+-
 Reporter:  DirkDatzert   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi,

 I have a related issue which behaves like ticket #9878 .

 I query a model.objects during an AJAX jQuery Autocomplete call which
 receives an simple http-request, does an orm-related query of the db and
 reponses with a single http-response. Example view and urls are attached.

 I run Django-1.0.X SVN 9684 with python-mysql 1.2.2 oder 1.2.3b1, Python
 2.4.2 on SLES10 and apache2-mod_python-3.1.3 under apache2-2.2.3.

 After one request the mysql db connection is left over in established mode
 on the client side and visible under SHOW PROCESSLIST via mysql cli as
 sleeping.

 Some threads in the internet told that this maybe a bug in python-mysql in
 relation to mod_python but an update of python-mysql to latest beta didn't
 resolve this. I have a second application running under the same apache2
 construct on the same host which didn't shows this idle connections. I
 connection is opened and closed correctly after a single HTTP-request.

 Regards,
 Dirk

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anih):

 Replying to [comment:36 liangent]:

 > in that marked line, if i don't specify force_update=True, it will do an
 INSERT, which will cause an IntegrityError. {{{ IntegrityError: (1062,
 "Duplicate entry '11' for key 1") }}}

 i try to reproduce this problem but without success, could you paste model
 file and separate some test?

 i send patch to trunk version with transaction.commit_unless_managed()
 inside select_for_update() (django/db/models/query.py)

 i dont have oracle to make some tests, but im using this patch with
 postgresql for about 1/2 year

-- 
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] #10401: Very long URL cause django error.

[Django]

#10401: Very long URL cause django error.
+---
  Reporter:  bigmonkey.bigmon...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:  handler404
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Comment:

 Duplicate of #10016

-- 
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] #10401: Very long URL cause django error.

[Django]

#10401: Very long URL cause django error.
---+
 Reporter:  bigmonkey.bigmon...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  HTTP handling  | Version:  1.0   
 Keywords:  handler404 |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I have configed the right handler404 for pages mismatching all the regular
 expressions in urls.py and it often worked fine.

 However when I entered a very long URLs with characters more than 250, the
 folloing error information would be listed:
 ==
 Traceback (most recent call last):

   File "/var/lib/python-
 support/python2.5/django/core/servers/basehttp.py", line 277, in run
 self.result = application(self.environ, self.start_response)

   File "/var/lib/python-
 support/python2.5/django/core/servers/basehttp.py", line 634, in __call__
 return self.application(environ, start_response)

   File "/var/lib/python-support/python2.5/django/core/handlers/wsgi.py",
 line 239, in __call__
 response = self.get_response(request)

   File "/var/lib/python-support/python2.5/django/core/handlers/base.py",
 line 67, in get_response
 response = middleware_method(request)

   File "/var/lib/python-support/python2.5/django/middleware/cache.py",
 line 125, in process_request
 cache_key = get_cache_key(request, self.key_prefix)

   File "/var/lib/python-support/python2.5/django/utils/cache.py", line
 163, in get_cache_key
 headerlist = cache.get(cache_key, None)

   File "/var/lib/python-
 support/python2.5/django/core/cache/backends/memcached.py", line 25, in
 get
 val = self._cache.get(smart_str(key))

   File "/var/lib/python-support/python2.5/memcache.py", line 619, in get
 check_key(key)

   File "/var/lib/python-support/python2.5/memcache.py", line 886, in
 check_key
 % SERVER_MAX_KEY_LENGTH)

 MemcachedKeyLengthError: Key length is > 250
 ==

 The above exception should be handled and be taken by handler404.

 Moreover, I test www.djangoproject.com, when I checked
 http://www.djangoproject.com/ladjflkjlkjlk, it gave me the right 404 page.

 But, When I visited
 
http://www.djangoproject.com/dsljfsldfdrewuroewrewroiewuroiewurewiuroiewurewoiruewoiruoiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewruewoiuroiewuroiewurewoiuroiewuroiewsljfsldfdrewuroewrewrsljfsldfdrewuroewrewrsljfsldfdrewuroewrewrsljfsldfdrewuroewrewr/

 My platform is FreeBSD 6.2, python 2.5.2, django 1.0.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-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] #10397: Add support for DATABASE_SUPPORTS_TRANSACTIONS to django.contrib.gis.tests.run_tests

[Django]

#10397: Add support for DATABASE_SUPPORTS_TRANSACTIONS to
django.contrib.gis.tests.run_tests
--+-
  Reporter:  mtredinnick  | Owner:  nobody
Status:  new  | Milestone:
 Component:  GIS  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by Almad):

 * cc: Almad (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

Re: [Django] #10400: File upload documentation should emphasize the need to add multipart/form-data

[Django]

#10400: File upload documentation should emphasize the need to add 
multipart/form-
data
+---
  Reporter:  claudep| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by claudep):

  * needs_better_patch:  => 0
  * summary:  File upload documentattion should emphasize the need to add
  multipart/form-data => File upload
  documentation should emphasize the need to add
  multipart/form-data
  * 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] #10400: File upload documentattion should emphasize the need to add multipart/form-data

[Django]

#10400: File upload documentattion should emphasize the need to add 
multipart/form-
data
---+
 Reporter:  claudep|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Even if it is explained in the request-response documentation
 (http://docs.djangoproject.com/en/dev/ref/request-
 response/#django.http.HttpRequest.FILES), I suggest to repeat the need to
 add multipart/form-data to the form tag in the 'File Upload'
 documentation. Following a patch which simply repeat the request-reponse
 note about it in the topics/http/file-uploads.txt doc file.

-- 
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 with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone: 
 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 liangent):

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

Comment:

 a problem...

 if I created a subclass of ModelForm, then added some FileField(s) which
 are not in the Model, the latest patch will raise {{{ FieldDoesNotExist:
 Xxx has no field named '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-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] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
---+
  Reporter:  robvdl| Owner:  ramiro 
   
Status:  new   | Milestone: 
   
 Component:  File uploads/storage  |   Version:  1.0
   
Resolution:|  Keywords:  upload image 
lowercase
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * owner:  nobody => ramiro

-- 
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] #9800: Syndication Framework could implement isPermaLink": "false" to better follow the recommendations of the RSS Advisory Board

[Django]

#9800: Syndication Framework could implement isPermaLink": "false"  to better
follow the recommendations of the RSS Advisory Board
+---
  Reporter:  martin   | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  RSS framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by julianb):

  * has_patch:  0 => 1

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

Re: [Django] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by liangent):

 another problem...
 {{{
 transaction.managed(True)
 transaction.set_dirty() # see comment above
 s =
 S.objects.select_for_update().filter(s='Q').order_by('pk')
 try:
 t = s[0]
 except IndexError:
 transaction.managed(False)
 time.sleep(2000)
 continue # there's a 'for' outside
 t.s = 'A'
 t.g = G.objects.get(pk=1)
 t.save(force_update=True) # mark
 transaction.managed(False)
 }}}
 in that marked line, if i don't specify force_update=True, it will do an
 INSERT, which will cause an IntegrityError. {{{ IntegrityError: (1062,
 "Duplicate entry '11' for key 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] #4501: Coverage support for tests

[Django]

#4501: Coverage support for tests
+---
  Reporter:  b...@almad.net | Owner:  ericholscher
Status:  new| Milestone:  
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by ericholscher):

 Looks like I need to be following doing the os.walk stuff inside of all
 the models/apps that I'm pulling in, and ignoring the tests actual code. I
 got some output that was interesting, but lacking a lot of detail that I
 needed. http://dpaste.com/5089/ I think I understand where I need to go
 from here, basically just making sure that I include all of the files
 inside an app (and not just the models.py, which is the "class"). I also
 don't need to be importing Django's test cases, because we're trying to
 get the coverage of the code, and not the tests.

 I'll take another swing at this later this week.

-- 
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] #4501: Coverage support for tests

[Django]

#4501: Coverage support for tests
+---
  Reporter:  b...@almad.net | Owner:  ericholscher
Status:  new| Milestone:  
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by ericholscher):

 I attached an initial patch that implements the functionality in the
 ./manage.py test runner. I have run into a couple of design decisiony
 things that I want to get feedback on while trying to create this patch.

 First off: Making it work for runtests.py and ./manage.py test means that
 logically I would want to put this code in Django's simple test runner. In
 order to do this, I would want to make a use_coverage argument to the
 run_tests() command. However, this is currently an exposed API, where
 people can write their own test runners. So if we try and pass another
 argument to it and someone is using a third party test runner, it will
 break. So that is out of the question.

 So the next logical thing to do would be to put the code into runtests.py
 and ./manage.py test, around the calls to run_tests, and then print out
 the results afterwards. This approach seems to make sense, and means that
 the common code should probably be moved out into a utils module some
 where. I threw a `start_coverage` and `stop_coverage` function into
 `django.test.utils`.

 This is a basic hashing out of what would eventually need to be committed.
 The API is currently ugly (start is passed verbosity so it knows when to
 print an error, this should probably just raise an exception and be
 handled in the client code with a try block). Stop is stopping (one line),
 and then printing out results. However, I just threw this together to see
 if this is the right direction to go in.

 Also of note, running the entire test suite with coverage.py takes a
 considerably longer amount of time than without. This makes sense, but
 hopefully there are some ways to speed things up. Without coverage
 enabled, the tests were taking around 280 seconds. With coverage enabled
 they took around 1400 seconds. Everything did pass though, it just took a
 long time. Presumably one won't be running with coverage enabled often, so
 this performance hit is manageable. I will be looking at ways to shave
 some time off though for sure.

 SQLAlchemy has an implementation of similar code here:
 
http://github.com/brosner/sqlalchemy/blob/a03faa1575bc3e1a56a93e0deb0f6ea7988c0491/test/testlib/config.py#L80

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