That's the main issue, yes. The master/slave split is not 1:1 with select/[insert|update|delete]. You have to be able to manually control whether a select query is "slave safe", which means an API change of one sort or another. A separate function or a flag are the two options. I'm a decidedly not politically correct person myself, but I'm not a big fan of "slave" either. It is, however, the accurate technical term and I haven't come up with a better name yet. Dries: Sorry to be picky, but did you mean "A period" or "option 1" (A for now, B for Drupal 7)? :-) I really don't like the idea of duplicating every query function long-term (meaning every alternate target or additional query variant multiples the number of functions we need), although I'm amenable to doing so for just one version. With an all-array structure the clumsy argument handling code disappears anyway. On Wednesday 01 August 2007, mark burdett wrote:
For functions like node_load, store_transaction_load (ecommerce module), etc -- there are times that you load an object and need the precise data that was just submitted. and other times you do not.
If these types of functions are using the slave queries then I guess it has to be documented that accurate data just isn't available? Unless, there were some parameter to pass in when you need to use the master.
--mark
On 8/1/07, andrew morton <drewish@katherinehouse.com> wrote:
Since d.o is having a fit right now I'll point to the google cache'd version of the issue: http://72.14.253.104/search?q=cache:QZEkIeazljEJ:drupal.org/node/147160+h ttp://drupal.org/node/147160
As long as it is I'd suggest reading through that, David Strauss pretty much gave a lecture and took notes for us ;)
On 8/1/07, Derek Wright <drupal@dwwright.net> wrote:
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>
In #60 Crell also expresses some reservations about the naming. Personally I don't think it's a big deal but maybe that's because I grew up setting master/slave jumpers on IDE drives.
<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?
Yeah, in #3 David Strauss discusses the problems with auto detection, basically there's some lag between when you write something and when it's propagated to the slave. If it's important that the query reflect recent changes you need to query the master. When you don't care, you can query a slave.
andrew
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson