On Fri, Jan 1, 2010 at 5:46 AM, CB <cbw...@gmail.com> wrote: Apologies for taking so long to get back to you on this - the silly season has been consuming a lot of my time.
> 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. I'd go one step further than an attribute - I'd provide a method. The default implementation would essentially be: def db_from_related_object(self, instance): return instance._state.db The related manager would then use the following: using = rel_mgr.db_for_source(instance) if getattr(rel_mgr, 'use_for_related_fields', False): rel_obj = rel_mgr.using(using).get(**params) else: rel_obj = QuerySet(self.field.rel.to).using(using).get(**params) In your use case, you would override this method on the AdSalesManager: def db_from_related_object(self, instance): return 'adsales' so no matter where the request for an AdSales object comes from, the adsales database will be used. If you wanted to implement a sharding strategy, you could put in more complex logic based on instance. > Do you think this flag addition is small enough for a bugfix / feature > in the 1.2 timeframe? Some sort of configuration in this direction will obviously be required in the long term, and it's arguably a bug in the current implementation - we need to expose a way to control the using() arrangements for related fields, and we don't currently do so. Given that this is a fairly glaring hole in the API, I'm certainly open to providing a fix in the 1.2 timeframe. My only question is whether we should try to make this public API for this release. I'm slightly hesitant to introduce API without a complete understanding of exactly how multi-db will be used in the field. For example, you've highlighted a problem on retrieval, but there will be an analogous problem on assignment - in the current implementation, book.author = user will force user onto the same database as book, (or force book onto the same database as user if book hasn't been db-assigned). This is obviously wrong for the use case your provide. So, my suggestion would be to introduce an API to solve this problem, but prefix the methods we add with underscores to highlight that this is internal API for now. Come 1.3, we can then change these API (either dropping the underscores, or replacing the underscore methods with an entirely new technique) without breaking backwards compatibility. Anyone using the internal API should be aware (because of the underscore) that there may be some migration work required to move from 1.2->1.3. Yours, Russ Magee %-) -- 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.