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.
