If your dev site is a seperate vserver, you can set environment variables to seperate these.
In you section of the conf file for your production server, use something like:
SetEnv DB prod_db
And, in the section for the dev environment you can:
SetEnv DB dev_db
Now, in your script, you can grab the DB environment variable to know which DB to connect to.
Why is $dbh global, BTW. Using Apache::DBI?
Cheers,
KM | [reply] |
I've never had a $dbh be a "global variable" in my mod_perl handlers. Always lexical. How are you writing your code such that it needs a global $dbh?
-- Randal L. Schwartz, Perl hacker | [reply] |
I'm not sure exactly what you are asking for here, but when
I write scripts using DBI and DBD, I always put the parameters
into variables (i.e. user name, password, db, server) so the
script can be easily modified.
if(! $U){ $U = "foo"; }
if(! $S){ $S = $ENV{"DSQUERY"};}
if(! $S){ $S = "sybase"; }
if(! $P){ $P = "foo_pw"; }
if(! $DB){ $DB = "info"; }
The above is specific to Sybase, which uses an interface
file and the DSQUERY environment variable to identify which
server to query. The necessary variables default to a
particular user name, password, server, and database, and will
permit the script to run on a command line as well as a cgi
script. If The script needs to query a different database,
then all the user needs to do is change the default variables
near the beginning of the script.
-----
"Computeri non cogitant, ergo non sunt" | [reply]
[d/l] |
What happens if you use a global hash. Would Apache::DBI cache the hash and allow multiple persisitant connections between different servers since the cached handle is bassed on the connect string.
i.e.
use strict;
use DBI;
use vars qw( %conn );
sub connect {
reread_conf("./config");
my $server = $config->{server};
my $db = $config->{db};
$conn{$db} ||= DBI->connect("dbi:$server:$db", ...);
}
my $dbh = connect();
Where reread_conf has the config hash for that app.
Would this work? I haven't tested it myself and would be interested to know.
| [reply]
[d/l] |