> Hrm, it's clear that the current implementation is probably overly > aggressive in changing the DB
I definitely agree here. It just seems like a useful working solution for 'now', clearly somethign a bit more elegant would be needed to make it into Django's core. > That being said in > your case it might make sense for using() to be a no-op, since by > definition your manager is supposed to work with a specific DB. Yes, and I think this is a somewhat common use case. If we could convince the related managers not to call .using() on the returned queryset (perhaps by means of a class attribute on the manager just like use_for_related_fields), we can drop the override of the .using() method on the queryset. Do you think this flag addition is small enough for a bugfix / feature in the 1.2 timeframe? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
