How to Switch Between Development, QA and Production Environments
We created that OCI8Hook class with database login and password abstraction
for a reason. In many corporations, you'll have multiple environments. You'll
want to build your code against the development environment, test it on a QA
environment and finally, if all goes well, send it out to a production
environment. Well, that's one more advantage to having your connection strings
abstracted into the function getDBAuth($sid) { ... } function.
To toggle between enviroments, simply change the connect string for your DBNAME.
Say I'm running all my queries against 'DBXYZ' with the following
$stmt = $this->query("DBXYZ", $sql, $bargs);. Change the connect string from this:
case "DBXYZ": return (array("usernam1", "secret1", "DBXYZ"));
to something like this:
case "DBXYZ": return (array("usernam1", "secret1", "TESTDB"));
Or if you wanted to be really fancy, you might consider sticking an IF
statement in there like this:
case "DBXYZ":
if (--I'm on the DEV environment--) {
return (array("usernam1", "secret1", "DEVDB"));
else if (--I'm on the QA environment--) {
return (array("usernam1", "secret1", "TESTDB"));
}
else {
return (array("usernam1", "secret1", "PRODDB"));
}
...
In Summary
The code I've shown you in this article may or may not work exactly from your
cut-and-paste. However, I use this same structure for writing all the Oracle
connectivity on my current projects...so I know it works. By abstracting the
authentication to a single location, I can manage my application's connection
strings much easier. By using the 'query' function for encapsulating all
queries, I gain a significant speed up in application development time. It
also helps to keep the code broken into distinct classes or 'objects'. When
it comes time to hunting down problems and making enhancements, you'll be glad
you abstracted the complicated portions of your PHP code so that you can
concentrate on the true business logic.
Dante Lorenso, dante@lorenso.com
Back to Database Journal