On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote: > At Pownce, for example, we stick users to the master database for some > period of time (a couple of seconds, usually) after they post a new note. > The problem here (as Malcolm pointed out) is that related managers use the > default manager for the related field. So if I ask for a User's Notes, the > default Note manager is used. That manager is, presumably, where the > decision is going to be made as to whether the slave or the master should be > queried. But the Note manager has no way of knowing whether the User is > stuck to the master -- it doesn't even know that there's a User associated > with the query...
That's really interesting. I wonder if that invalidates the whole approach I proposed, or merely means it needs some refining? > Simon, from your first email it seems you're suggesting that the Manager > call Query.as_sql() and then parse the resulting SQL string? Not at all - I'm suggesting the manager pokes around at the query object itself (what type of query is it, which tables does it touch etc). I mentioned as_sql as a throw-away remark; I certainly wouldn't want to suggest implementing connection selection logic in that way. > IMO, the right place for a decision like "should this User's notes come from > the master, or the slave?" is on the User model (or maybe User manager), > not in the Note manager. It's possible that the Note manager simply won't have enough information to make that decision - in which case I'd suggest that solving it is up to the developer. They might chose to use the 'using()' method to force a query through notes to go to the slave, for example. > The same problem comes up with sharding. Suppose, for example, Pownce > started sharding by User and putting each User's Notes on the same server > the User is on. We should be able to call User.notes.all() and get that > User's notes, but the Note manager can't easily tell what server it should > be querying, since it doesn't know about the User. Again, you could start > poking at the internals of Query and try to figure out what's going on, but > that doesn't seem like a particularly elegant solution... Again, my assumption is that in that case it's up to the developer to ensure queries go to the right place - maybe by adding their own "get_notes" method to their user object that automatically queries the correct shard (with the using() method). I'm not convinced that this stuff can be made invisible to the developer - if you're sharding things you're in pretty deep, and you probably want to maintain full control over where your queries are going. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
