On Aug 1, 2007, at 3:50 PM, andrew morton wrote:
I'd prefer to use db_query_slave(). It makes it simple to direct safe queries to the slave with a minimum of changes.
<politically_correct type="proud"> Am I the only one who recoils at the usage of the word "slave" for this? Do we really have to let that word get all the way into the Drupal core API itself? :( While I'm sure some of the people on this list would think it's funny, no one in their right mind would call this "db_query_bitch()", either, even though to some, it'd have basically the same meaning. *sigh* </politically_correct> If we're going to use a separate query function for queries that can be directed to the read-only DB(s), why not call it something like "db_query_read()"? Pardon my ignorance in split DB configurations and queries, but are there any read-only queries that aren't safe for this? Don't we just have to direct SELECT queries one way, and UPDATE or INSERT queries another? <idea type="crazy"> Can't we just parse the query and see if it contains any UPDATE or INSERT clauses? ;) Why do we need to change the API at all? </idea> I suppose the problem is queries that SELECT to check a value and then update it, and you'd want to do both of those on the primary DB. That's why we either need transaction awareness, or we need the query author to specify what they need explicitly. Is that the issue? Even still, an explicit "db_query_read()" for read-only queries you know are safe for secondary DB servers seems the most logical to me. We'd never write to the secondary servers, correct? Cheers, -Derek (dww-the-commie-pinko-who's-no-DBA)