Re: [Django] #9188: Postgresql 'missing FROM-clause entry in subquery for table' error on lookup that spans relationships

[Django]

#9188: Postgresql 'missing FROM-clause entry in subquery for table' error on
lookup that spans relationships
---+
  Reporter:  naitsirhc | Owner:  
mtredinnick  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
Postgresql,join,relationships
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by bhagany):

 Replying to [comment:6 mtredinnick]:

 Heh, I don't think anybody expects you to remember every duplicate ticket
 :).  If you need anything else to fail all the time, just let me know.  I
 seem to have a knack.

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

[Django] #9764: IDN (Internationalized Domain Names) support for EmailField and URLField

[Django]

#9764: IDN (Internationalized Domain Names) support for EmailField and URLField
---+
 Reporter:  UloPe  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Currently EmailField and URLField don't accept values that contain IDNs.

 The submitted patch adds this capability.

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

Re: [Django] #9188: Postgresql 'missing FROM-clause entry in subquery for table' error on lookup that spans relationships

[Django]

#9188: Postgresql 'missing FROM-clause entry in subquery for table' error on
lookup that spans relationships
---+
  Reporter:  naitsirhc | Owner:  
mtredinnick  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
Postgresql,join,relationships
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 Excellent. Thanks, Brent. Sorry for forgetting about the example on the
 duplicate ticket. I don't know why my almost identical case didn't trigger
 this, but you win the prize for "simplest possible example." Fails
 reliably now (only in debugging is this considered a good thing).

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

Re: [Django] #9763: is_dirty() in the transactions middleware blocks commit for Postgre

[Django]

#9763: is_dirty() in the transactions middleware blocks commit for Postgre
---+
  Reporter:  Jeffrey   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Jeffrey):

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

Comment:

 See:

  *
 
http://code.djangoproject.com/browser/django/trunk/django/middleware/transaction.py

  *
 http://code.djangoproject.com/browser/django/trunk/django/db/transaction.py

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

[Django] #9763: is_dirty() in the transactions middleware blocks commit for Postgre

[Django]

#9763: is_dirty() in the transactions middleware blocks commit for Postgre
--+-
 Reporter:  Jeffrey   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 In its default operation Postgre makes a shadow copy of a table for
 reading, and this persists until you explicitly commit your transaction.
 However, the TransactionsMiddleware class only calls commit when
 transaction.is_dirty() returns true.  If you only read from the database,
 commit will never get called.

 Possibly the is_dirty() check should be bypassed (or perhaps always return
 True) for postgres.

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

Re: [Django] #9730: When using model inheritance, raw_id_fields returns a model's name in the input field.

[Django]

#9730: When using model inheritance, raw_id_fields returns a model's name in the
input field.
---+
  Reporter:  grantmoney| Owner:  mtredinnick
Status:  closed| Milestone: 
 Component:  django.contrib.admin  |   Version:  1.0
Resolution:  duplicate |  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 Yes, well spotted. I knew I'd seen this before somewhere.

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

Re: [Django] #9461: raw id fields for inherited models in inline intermediate models show base class __unicode__ rather than id

[Django]

#9461: raw id fields for inherited models in inline intermediate models show 
base
class __unicode__ rather than id
---+
  Reporter:  Jacob Smullyan <[EMAIL PROTECTED]>  | Owner:  
mtredinnick
Status:  assigned  | Milestone: 

 Component:  django.contrib.admin  |   Version:  
1.0
Resolution:|  Keywords: 

 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 Closing #9730 as a dupe of this. Only noting that here because #9730
 contains another full example if it's needed.

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

Re: [Django] #8363: Make runtests.py able to run all tests but the ones specified by prefixing its names with '-'

[Django]

#8363: Make runtests.py able to run all tests but the ones specified by 
prefixing
its names with '-'
+---
  Reporter:  ramiro | Owner:  nobody  
Status:  new| Milestone:  post-1.0
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  1  |  
+---
Changes (by ramiro):

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

Re: [Django] #9752: select_related on query on model with GeoManager as default manager breaks

[Django]

#9752: select_related on query on model with GeoManager as default manager 
breaks
-+--
  Reporter:  seanl   | Owner:  nobody  
Status:  closed  | Milestone:  post-1.0
 Component:  GIS |   Version:  1.0 
Resolution:  fixed   |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by jbronn):

 Replying to [comment:1 jbronn]:
 > Fixed r9572.  New I got something mixed up with this ticket number and
 revision number.
 *sigh*

 time to get some sleep.

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

Re: [Django] #9752: select_related on query on model with GeoManager as default manager breaks

[Django]

#9752: select_related on query on model with GeoManager as default manager 
breaks
-+--
  Reporter:  seanl   | Owner:  nobody  
Status:  closed  | Milestone:  post-1.0
 Component:  GIS |   Version:  1.0 
Resolution:  fixed   |  Keywords:  
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 Fixed r9572.  New I got something mixed up with this ticket number and
 revision number.

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

[Changeset] r9573 - in django/branches/releases/1.0.X/django/contrib/gis: db/models/sql tests/relatedapp

[noreply]

Author: jbronn
Date: 2008-12-05 20:01:38 -0600 (Fri, 05 Dec 2008)
New Revision: 9573

Modified:
   django/branches/releases/1.0.X/django/contrib/gis/db/models/sql/query.py
   django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/models.py
   django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/tests.py
Log:
[1.0.X] Fixed #9572 -- use `opts` argument.  Thanks SeanL for bug report and 
patch.

Backport of r9572 from trunk.


Modified: 
django/branches/releases/1.0.X/django/contrib/gis/db/models/sql/query.py
===
--- django/branches/releases/1.0.X/django/contrib/gis/db/models/sql/query.py
2008-12-06 01:52:14 UTC (rev 9572)
+++ django/branches/releases/1.0.X/django/contrib/gis/db/models/sql/query.py
2008-12-06 02:01:38 UTC (rev 9573)
@@ -122,7 +122,7 @@
 table_alias = start_alias
 else:
 table_alias = self.tables[0]
-root_pk = self.model._meta.pk.column
+root_pk = opts.pk.column
 seen = {None: table_alias}
 aliases = set()
 for field, model in opts.get_fields_with_model():

Modified: 
django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/models.py
===
--- 
django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/models.py
2008-12-06 01:52:14 UTC (rev 9572)
+++ 
django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/models.py
2008-12-06 02:01:38 UTC (rev 9573)
@@ -11,3 +11,12 @@
 state = USStateField()
 location = models.ForeignKey(Location)
 objects = models.GeoManager()
+
+class AugmentedLocation(Location):
+extra_text = models.TextField(blank=True)
+objects = models.GeoManager()
+
+class DirectoryEntry(models.Model):
+listing_text = models.CharField(max_length=50)
+location = models.ForeignKey(AugmentedLocation)
+objects = models.GeoManager()

Modified: 
django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/tests.py
===
--- django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/tests.py 
2008-12-06 01:52:14 UTC (rev 9572)
+++ django/branches/releases/1.0.X/django/contrib/gis/tests/relatedapp/tests.py 
2008-12-06 02:01:38 UTC (rev 9573)
@@ -2,7 +2,7 @@
 from django.contrib.gis.geos import *
 from django.contrib.gis.tests.utils import no_mysql, postgis
 from django.conf import settings
-from models import City, Location
+from models import City, Location, DirectoryEntry
 
 cities = (('Aurora', 'TX', -97.516111, 33.058333),
   ('Roswell', 'NM', -104.528056, 33.387222),
@@ -89,6 +89,11 @@
 u2 = 
City.objects.exclude(name='Roswell').unionagg(field_name='location__point')
 self.assertEqual(ref_u1, u1)
 self.assertEqual(ref_u2, u2)
+
+def test05_select_related_fk_to_subclass(self):
+"Testing that calling select_related on a query over a model with an 
FK to a model subclass works"
+# Regression test for #9752.
+l = list(DirectoryEntry.objects.all().select_related())
 
 # TODO: Related tests for KML, GML, and distance lookups.
 


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

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

[noreply]

Author: jbronn
Date: 2008-12-05 19:52:14 -0600 (Fri, 05 Dec 2008)
New Revision: 9572

Modified:
   django/trunk/django/contrib/gis/db/models/sql/query.py
   django/trunk/django/contrib/gis/tests/relatedapp/models.py
   django/trunk/django/contrib/gis/tests/relatedapp/tests.py
Log:
Fixed #9572 -- use `opts` argument.  Thanks SeanL for bug report and patch.


Modified: django/trunk/django/contrib/gis/db/models/sql/query.py
===
--- django/trunk/django/contrib/gis/db/models/sql/query.py  2008-12-06 
01:24:59 UTC (rev 9571)
+++ django/trunk/django/contrib/gis/db/models/sql/query.py  2008-12-06 
01:52:14 UTC (rev 9572)
@@ -122,7 +122,7 @@
 table_alias = start_alias
 else:
 table_alias = self.tables[0]
-root_pk = self.model._meta.pk.column
+root_pk = opts.pk.column
 seen = {None: table_alias}
 aliases = set()
 for field, model in opts.get_fields_with_model():

Modified: django/trunk/django/contrib/gis/tests/relatedapp/models.py
===
--- django/trunk/django/contrib/gis/tests/relatedapp/models.py  2008-12-06 
01:24:59 UTC (rev 9571)
+++ django/trunk/django/contrib/gis/tests/relatedapp/models.py  2008-12-06 
01:52:14 UTC (rev 9572)
@@ -11,3 +11,12 @@
 state = USStateField()
 location = models.ForeignKey(Location)
 objects = models.GeoManager()
+
+class AugmentedLocation(Location):
+extra_text = models.TextField(blank=True)
+objects = models.GeoManager()
+
+class DirectoryEntry(models.Model):
+listing_text = models.CharField(max_length=50)
+location = models.ForeignKey(AugmentedLocation)
+objects = models.GeoManager()

Modified: django/trunk/django/contrib/gis/tests/relatedapp/tests.py
===
--- django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2008-12-06 
01:24:59 UTC (rev 9571)
+++ django/trunk/django/contrib/gis/tests/relatedapp/tests.py   2008-12-06 
01:52:14 UTC (rev 9572)
@@ -2,7 +2,7 @@
 from django.contrib.gis.geos import *
 from django.contrib.gis.tests.utils import no_mysql, postgis
 from django.conf import settings
-from models import City, Location
+from models import City, Location, DirectoryEntry
 
 cities = (('Aurora', 'TX', -97.516111, 33.058333),
   ('Roswell', 'NM', -104.528056, 33.387222),
@@ -89,6 +89,11 @@
 u2 = 
City.objects.exclude(name='Roswell').unionagg(field_name='location__point')
 self.assertEqual(ref_u1, u1)
 self.assertEqual(ref_u2, u2)
+
+def test05_select_related_fk_to_subclass(self):
+"Testing that calling select_related on a query over a model with an 
FK to a model subclass works"
+# Regression test for #9752.
+l = list(DirectoryEntry.objects.all().select_related())
 
 # TODO: Related tests for KML, GML, and distance lookups.
 


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

[Changeset] r9571 - django/branches/releases/1.0.X/django/contrib/gis

[noreply]

Author: jbronn
Date: 2008-12-05 19:24:59 -0600 (Fri, 05 Dec 2008)
New Revision: 9571

Modified:
   django/branches/releases/1.0.X/django/contrib/gis/shortcuts.py
Log:
[1.0.X] Fixed #9742 -- remove extraneous 'kml' from KML mimetype.  Thanks, 
robotika for the bug report.

Backport of r9570 from trunk.


Modified: django/branches/releases/1.0.X/django/contrib/gis/shortcuts.py
===
--- django/branches/releases/1.0.X/django/contrib/gis/shortcuts.py  
2008-12-06 00:38:48 UTC (rev 9570)
+++ django/branches/releases/1.0.X/django/contrib/gis/shortcuts.py  
2008-12-06 01:24:59 UTC (rev 9571)
@@ -14,7 +14,7 @@
 def render_to_kml(*args, **kwargs):
 "Renders the response as KML (using the correct MIME type)."
 return HttpResponse(loader.render_to_string(*args, **kwargs),
-mimetype='application/vnd.google-earth.kml+xml kml')
+mimetype='application/vnd.google-earth.kml+xml')
 
 def render_to_kmz(*args, **kwargs):
 """


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

Re: [Django] #6447: memcached does not support arbitrary string keys

[Django]

#6447: memcached does not support arbitrary string keys
---+
  Reporter:  nicois <[EMAIL PROTECTED]>  | Owner:  nobody   
Status:  reopened  | Milestone: 
  
 Component:  Cache system  |   Version:  SVN
  
Resolution:|  Keywords:  
memcached
 Stage:  Design decision needed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by wam):

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

Comment:

 This ticket was apparently closed because #7460 dealt with bad keys and a
 solution was committed for that ticket. The problem is that this happened
 only at the template tag interface. Applications that use the low level
 interface to the cache system still break with bad keys. The documentation
 for the cache system still does not mention this limitation of the
 memcache backend, and having inconsistent keying limitations (especially
 one of such a basic level as whitespace vs no whitespace) in various
 backends makes it much harder to build reusable apps (a cache key that
 works for my localmem:// cache may not work with the memcached backend
 being used on someone elses server).

 Ideally, I'd like to see the memcached backend have similar logic applied
 to it as was used in in #7460 (e.g. use urlquote to ensure keys have no
 spaces in them) so that all interfaces are protected from spaces. Lacking
 that, I'd suggest an update to the cache docs that draws attention to
 memcached's limitation and provides a recommendation to application
 programmers who are writing applications that use the low-level cache
 layer to always escape their keys if their app might be used on a server
 that utilizes memcached.

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

[Django] #9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE different than english

[Django]

#9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE
different than english
--+-
 Reporter:  amele |   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Template system   | Version:  SVN   
 Keywords:  date template filter  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Documentation says template filter date with argument 'r' returns a valid
 RFC 2822 formatted date. But setting a LANGUAGE_CODE different than
 english makes the date returned not valid because the day abbreviation is
 translated into the LANGUAGE_CODE language. Perhaps there should be two
 arguments for this: one for valid RFC 2822 dates and another one for the
 actual 'r' argument (RFC 2822 translated).

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

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+--
  Reporter:  svetlyak40wt| Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Core framework  |   Version:  1.0  
   
Resolution:  |  Keywords:  model inheritance, 
signals, dispatch
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Comment (by Alex):

 Why not just use klass.__bases__ to avoid any special dependence on
 knowing it's a model.  I realize it isn't a common case to have signals
 who's sender isn't a model, but I don't see any overhead in allowing it.

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

Re: [Django] #9730: When using model inheritance, raw_id_fields returns a model's name in the input field.

[Django]

#9730: When using model inheritance, raw_id_fields returns a model's name in the
input field.
---+
  Reporter:  grantmoney| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by jsmullyan):

 This is, I believe, a dupe of #9461, or vice versa.

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

[Django] #9761: Enhancement CacheBackend API

[Django]

#9761: Enhancement CacheBackend API
--+-
 Reporter:  fero  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Cache system  | Version:  1.0   
 Keywords:  cache API |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 In order to make the CacheBackend easily used by custom cache middleware
 component (which is application aware),
 I think it should be appropriate to add two methods

 {{{
 when_cached(self, key) --> the timestamp of the cached key if present, 0
 otherwise
 get_if_newer(self, key, timestamp) --> get only if "when_cached" timestamp
 is more than the timestamp in input
 }}}

 The former is a MUST to implement custom cache middleware,

 the latter is a BONUS but is trivial to implement it in custom cache
 middleware too (if the first is present)

 I attach a patch to filebased.py CacheClass in order to show the
 implementation for file based cache

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

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+--
  Reporter:  svetlyak40wt| Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Core framework  |   Version:  1.0  
   
Resolution:  |  Keywords:  model inheritance, 
signals, dispatch
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Comment (by telenieko):

 I guess you are talking about:
 {{{
 #!python
  from django.db import models

  class Parent(models.Model):
 """
 >>> p = Parent(name="Hola")
 >>> p.save()
 Hello!
 """
 name = models.CharField(max_length=10, blank=True, default='')

  class Child(Parent):
 """
 >>> p = Child(name="Hola ahora")
 >>> p.save()
 Hello!
 """
 childname = models.CharField(max_length=10, blank=True, default='')

  from django.db.models.signals import post_init
  from django.db.models.signals import post_save

  def say_hello(sender, *args, **kwargs):
  print "Hello!"
  post_save.connect(say_hello, sender=Parent)
 }}}

 ?? The doctest that fails (the one in Child) should be considered a bug.

 One would really expect that it's signal handlers still fire on a class
 althought having been inherited (I'd guess that's how most languages
 handle this).

 A side, reading the docs about pre_init and post_init, you'd expect that
 if you Model's __init__() method is run, handlers attached to this should
 also be fired, which isn't the case.

 So, in brief, handlers attached to a Model should be fired when signals
 get sent from Child Models. Having it disabled by default can confuse
 people, but maybe we could disable this until 2.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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9188: Postgresql 'missing FROM-clause entry in subquery for table' error on lookup that spans relationships

[Django]

#9188: Postgresql 'missing FROM-clause entry in subquery for table' error on
lookup that spans relationships
---+
  Reporter:  naitsirhc | Owner:  
mtredinnick  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  
Postgresql,join,relationships
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by bhagany):

 Replying to [comment:4 mtredinnick]:
 > As I mentioned in the original thread, this description doesn't contain
 all the information needed to replicate the problem. It refers to a "user"
 model that isn't described anywhere and uses a custom manager
 (`object_all`). I can't repeat the bug using a normal manager and two
 models pointing to a third common model.
 >
 > So I'll either need a complete set of models that is self-contained and
 replicates the problem or a patch against
 `django/regressiontests/queries/models.py` that fails with the same
 problem. At the moment, I'm a bit stuck as to how to reveal the problem
 and it's not caused by what I thought might have been the issue.

 This is the attachment I put on the ticket I opened about this (#9192),
 which includes three very simple models that replicate this issue.  I
 haven't tried it against a recent revision, but I don't think any major
 changes have been made that would affect this behavior.

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

[Django] #9760: Documentation should warn that mixing positional and keyword arguments in url tag does not work

[Django]

#9760: Documentation should warn that mixing positional and keyword arguments in
url tag does not work
-+--
 Reporter:  eibaan   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 #8764 makes it clear that the {{{url}}} tag cannot mix args and kwargs
 however the documentation isn't clear about this and actually, the
 [http://docs.djangoproject.com/en/dev/ref/templates/builtins/#url example]
 shown is one that mixes positional and keyword arguments.

 I'd suggest to rephrase this like so:
 {{{
 {% url path.to.some_view arg1,arg2 %}
 or
 {% url path.to.some_view name1=value1,name2=value2 %}

 The first argument is a path to a view function in the format
 package.package.module.function. Additional arguments are optional
 and should be comma-separated values that will be used as either
 positional or  keyword arguments in the URL. Do not mix positional
 and keyword arguments in on statement. All arguments required by
 the URLconf should be present.
 }}}

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