> Apologies for taking so long to get back to you on this - the silly > season has been consuming a lot of my time.
Silly season indeed :) > I'd go one step further than an attribute - I'd provide a method. I was considering this, but I was thinking about a hacky/internal API for 1.2 instead of doing the full implementation that I read was being thrown around :) I suppose it is an easy logical extention. > The > default implementation would essentially be: > > def db_from_related_object(self, instance): > return instance._state.db I'm not familiar with ._state and not sure if you're referencing existing attributes on the manager, but I can see what you're getting at. > 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) Yes, exactly. I didn't want to jump in much further than I had to, so I haven't actually patched this (monkey patching is fun, heh) as a quick guess is it needs to be done in another place for M2M. I have merely passing familiarity with this stuff, until the other day I wasn't even aware of these 'magic' descriptors in django. > 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. Agreed. > 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. This does seem to be the biggest issue at the moment. > Given > that this is a fairly glaring hole in the API, I'm certainly open to > providing a fix in the 1.2 timeframe. I'm not too familiar with when exactly this timeframe is - if it's still a bit away and this doesn't count as a 'feature' (i.e., I have maybe a week or so) I might try writing up a patch. > My only question is whether we should try to make this public API for > this release. Without an understanding of exactly how soon you want 1.2 out, and as I'm not exactly the best unit tester... ;) I think keeping this an internal API might be best for now until someone a bit more knowledgeable about the internal plumbing than me weighs in on these ideas. > 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. I totally forgot about assignment! In the monkeypatched code I posted before, assignment (seemingly) works by segregating the models across DB (that is, keeping all instances of a model on a single db) by basically making the default implementation return 'default' instead of keeping the 'from whence it came' strategy for related models. We probably should name / detail these partitioning strategies so we can discuss them easier: 1. Follow Original DB: Always resolve relations by staying on the same DB as the source relation 2. Force Model DB: Always resolve relations by using The code I posted above sticks with option 2, and treats an un- dbassigned model as assigned to 'default'. > 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. Agreed. -- 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.
