use DBI;
$dbh = DBI->connect("dbi:Proxy:hostname=$host;port=$port;dsn=$db",
$user, $passwd);
# See the DBI module documentation for full details
This is of course not needed for DBI drivers which already support connecting to a remote database, but there are engines which don't offer network connectivity.
Another application is offering database access through a firewall, as the driver offers query based restrictions. For example you can restrict queries to exactly those that are used in a given CGI application.
Speaking of CGI, another application is (or rather, will be) to reduce the database connect/disconnect overhead from CGI scripts by using proxying the connect_cached method. The proxy server will hold the database connections open in a cache. The CGI script then trades the database connect/disconnect overhead for the DBD::Proxy connect/disconnect overhead which is typically much less.
Say, your Proxy server is running on machine ``alpha'', port 3334, and you'd like to connect to an ODBC database called ``mydb'' as user ``joe'' with password ``hello''. When using DBD::ODBC directly, you'd do a
$dbh = DBI->connect("DBI:ODBC:mydb", "joe", "hello");
With DBD::Proxy this becomes
$dsn = "DBI:Proxy:hostname=alpha;port=3334;dsn=DBI:ODBC:mydb"; $dbh = DBI->connect($dsn, "joe", "hello");
You see, this is mainly the same. The DBD::Proxy module will create a connection to the Proxy server on ``alpha'' which in turn will connect to the ODBC database.
Refer to the DBI documentation on the "connect" method for a way to automatically use DBD::Proxy without having to change your code.
DBD::Proxy's DSN string has the format
$dsn = "DBI:Proxy:key1=val1; ... ;keyN=valN;dsn=valDSN";
In other words, it is a collection of key/value pairs. The following keys are recognized:
hostname=alpha;port=3334
dsn=DBI:ODBC:mydb
cipher=$class;key=$key
(note the semicolon) then DBD::Proxy will create a new cipher object by executing
$cipherRef = $class->new(pack("H*", $key));
and pass this object to the RPC::PlClient module when creating a client. See RPC::PlClient. Example:
cipher=IDEA;key=97cd2375efa329aceef2098babdc9721
The usercipher/userkey attributes allow you to use two phase encryption: The cipher/key encryption will be used in the login and authorisation phase. Once the client is authorised, he will change to usercipher/userkey encryption. Thus the cipher/key pair is a host based secret, typically less secure than the usercipher/userkey secret and readable by anyone. The usercipher/userkey secret is your private secret.
Of course encryption requires an appropriately configured server. See ``CONFIGURATION FILE'' in DBD::ProxyServer.
stderr=1
logfile=/dev/null
However, if you set the proxy_no_finish attribute to a TRUE value, either in the database handle or in the statement handle, then finish() calls will be suppressed. This is what you want, for example, in small and fast CGI applications.
However, if you set the proxy_quote attribute to the value '"local"' either in the database handle or in the statement handle, and the call to quote has only one parameter, then the local default DBI quote method will be used (which will be faster but may be wrong).
sub DBD::Proxy::db::selectall_arrayref;
That will enable selectall_arrayref to be proxied.
Currently many methods aren't explicitly proxied and so you get the DBI's default methods executed on the client.
Some of those methods, like selectall_arrayref, may then call other methods that are proxied (selectall_arrayref calls fetchall_arrayref which calls fetch which is proxied). So things may appear to work but operate more slowly than the could.
This may all change in a later version.
$dbh->{"csv_tables"}->{"passwd"} =
{ "sep_char" => ":", "eol" => "\n";
The above example would advice the CSV driver to assume the file ``passwd'' to be in the format of the /etc/passwd file: Colons as separators and a line feed without carriage return as line terminator.
Surprisingly this example doesn't work with the proxy driver. To understand the reasons, you should consider the following: The Perl compiler is executing the above example in two steps:
This becomes a little bit clearer, if we rewrite the above code:
$tables = $dbh->{"csv_tables"};
$tables->{"passwd"} = { "sep_char" => ":", "eol" => "\n";
While the examples work fine without the proxy, the fail due to a subtle difference in step 1: By DBI magic, the hash ref $dbh->{'csv_tables'} is returned from the server to the client. The client creates a local copy. This local copy is the result of step 1. In other words, step 2 modifies a local copy of the hash ref, but not the server's hash ref.
The workaround is storing the modified local copy back to the server:
$tables = $dbh->{"csv_tables"};
$tables->{"passwd"} = { "sep_char" => ":", "eol" => "\n";
$dbh->{"csv_tables"} = $tables;
Jochen Wiedmann
Am Eisteich 9
72555 Metzingen
Germany
Email: joe@ispsoft.de
Phone: +49 7123 14887
The DBD::Proxy module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. In particular permission is granted to Tim Bunce for distributing this as a part of the DBI.