Sorry if a made a mistake, but i reopened #7666 for a reason mentioned in the ticket (i hope i stepped on no ones toes by doing that)
the comment reads as follows """ this change, effectively kills "get" overloading in Managers i can think of a million reasons way this is necessary, caching these 'gets' in some local/thread/memcached world 'special gets' (deleted flags and permissions) database sharding, etc, etc i hope y'all re think this before Versions 1, so i'm reopening this as since the 'QuerySet?' approach you took has no ability to be overloaded """ bo On Jul 22, 9:37 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Tue, Jul 22, 2008 at 8:38 AM, Justin Bronn <[EMAIL PROTECTED]> wrote: > > Using a "pristine" QuerySet is a bad assumption to make, especially > > for those who are using custom managers to properly generate SQL for > > non-standard columns, e.g., geometries. The patch committed in r8011 > > has the unintended side-effect of breaking related geographic queries > > for MySQL and Oracle because it bypasses the default manager > > (GeoManager) and thus does not know how to properly select geometry > > columns. > > Nuts -- I didn't think of that. Sorry! > > > One possible solution would be look for the presence of an attribute > > on the default manager so that it used instead of QuerySet. > > Hrm, so django/trunk/django/db/models/fields/related.py:240 becomes:: > > rel_obj = > self.field.rel.to._default_manager.get_pristine_queryset().get(**params) > > (assuming an appropriate get_pristine_queryset() funtion)? > > Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
