Thanks to all, and apologies to all. I should have waited another day to flesh this out before sending, but I was trying to take advantage of living on the west coast of the USA to send this out last night and come to work this morning to find my inbox teeming with lots of interesting ideas. Dumb, dumb, dumb (and selfish).
On 7/19/07, Tim Bunce <[EMAIL PROTECTED]> wrote:
It's not really clear what you're trying to do.
Suppose I have a database with a table with two columns, 'key' and 'value'. (This is a simplification, of course.) The contents of this database determine how my software interacts. The database is read-only, as far as the software is concerned; this should make the implementation simpler. Now, suppose I'd like to test out the result of adding or updating some new key-value pairs in this database. What I'd like to do is have a local database table to put these temporary key-value pairs in, and have my software obtain a $dbh that makes it transparent to the software that it's really looking at two tables, mixing their data together as one. By the way, when I say "my software", I mean software written by the company that isn't really amenable to changing, which is why I thought of the DBI_AUTOPROXY approach (see below). But I could hack a local copy of it if necessary.
From what you say below it seems that you just want to "just change the env var to switch between servers". That's relatively simple but doesn't seem to match what you said above.
What I intended was that I could use the environment variable to switch between "normal", using just the one database, or "test", adding in the data from the new database as well. Since I usually have more than one "test" database, having a switch would really help.
> My thoughts have turned to something like DBD::Proxy, because then I > could just change the environment variable DBI_PROXY when needed to > switch between servers. Perhaps you could just use the DBI_AUTOPROXY env var to force a different DSN without using DBD::Proxy.
Although I got the name of the environment variable wrong, I'm glad to see you caught what I had in mind and seem to think it's a possibility. The trouble is determining what this different DSN would be. I don't know of any DBDs that act the way I have envisioned above.
DBD::Multiplex may be worth exploring. (I have a modified and more flexible version I worked on a couple of years ago that never quite got polished up and released. It should probably be renamed as it's slightly incompatible with the old one. Volunteers welcome.)
I did take a look at DBD::Multiplex, but it struck me that it was intended for situations in which there are multiple servers with duplicate contents: each database has the same data in it, so you can read any server you want, and a write operation propagates that change to each of the servers, keeping them in sync. The situation I envision is of multiple servers whose contents are not the same. But I'll take another look at the module if you think it warrants it. Theron
