Front page | perl.dbi2.dev |
Postings from October 2005
Re: Drivers and Data Source Names
From: Honza Pazdziora
October 4, 2005 23:47
Re: Drivers and Data Source Names
Message ID: 20051005064657.GA16817@anxur.fi.muni.cz
On Tue, Oct 04, 2005 at 02:39:07PM +0100, Tim Bunce wrote:
> XXX need to consider handling of unknown attributes (ie version skew)
> and driver-private attributes. c.f. JDBC 4 wrapper pattern.
> Separate client-side attributes from server/db-side?
What are client-side attributes and what are server-side ones? Can't
client-side attribute for one driver be server-side for another one?
> =head2 Wrapping/Nesting Drivers
> It should be simple to wrap one driver within another in order to enhance or
> modify the behaviour of the wrapped driver.
By wrap, you mean inherit (in OO way)?
> The DBI should provide a set of base classes that implement a 'transparent'
> wrapper driver.
> The logging and profiling of DBI method calls, currently embedded into the
> Perl5 DBI method dispatcher, could then be implemented by creating subclasses
> of the transparent wrapper driver.
I might have missed the resolution from the is-a/has-a discussion, but
I find it rather nice that DBI does all the dispatching and that
order and calling of individual parts is handled not by the driver
side, but by the DBI layer. The driver just plugs handlers into
appropriate outlets (by defining the methods), but the general logic
on top of that is stable and the same for all drivers.
What is the benefit of these transparent wrapper drivers? Having some
complex profiling code out of DBI core so that it does not slow down
the typical usage? In that case I'd rather see this code as a backend
part of DBI extensions, than leave it in the driver side. My reason?
I did not update the DBD::XBase for very long time and it still does
correctly most of the things that the driver is supposed to do (even
if I got a bug report about table_info just yesterday). Why? Because
most of the new DBI specs is handled by the default DBI methods and my
DBD does not feel like it needs to override much.
> The same mechanism could form the basis of many enhancements such as lazy
> connections, SQL rewriting, simple replication/clustering etc.
Again, it seems to me that these are example of DBI extensions (on top
/ around the core), rather than DBD-side.
> Some generic and specific examples:
> dbi:/driver/dbname #?assumes localhost unless driver and dbname imply otherwise
Tim, how does Oracle EZconnect fit in here?
Do you think that it is possible normalize all databases to this
dbi:/driver/dbname style? How about dbi:/driver/cluster/dbname or
> This works well for most cases except where the datasource is specified by a
> path containing slashes. The forward slash characters need to be escaped:
> but that's hardly friendly, so there's a possible alternative form:
> or, as the file path logically corresponds to the host:port portion:
> Here the "&" character represents whatever is in the query portion of the URI.
Hmmm, seems a bit unreadable.
> Some level of indirection is needed in the interpretation of DSNs.
> Multiple 'driver manager like' entities can be given the opportunity to
> accept or decline to provide a connection for the given DSN.
> This indirection may be used to implement auto proxying or other kinds of
> driver layering where one driver recurses into the driver manager to find
> the 'real' driver for the DSN that it will then wrap.
> The plugin multiple driver managers can also implement name service lookups
> to map simple names (like "dbi:sales") into full DSNs via some external
> service like LDAP or even a ~/.dbi file. See JDBCs use of JNDI.
> A 'driver' could also only serve the purpose of determining which real driver
> you wanted to use. Consider this URI:
> The 'dsnuri' driver could open the ~/.dbi-dsn.txt text file and read the DBI URI
> identified as 'myname' (ignoring the details of how it's identified for now)
> and then load that URI. Similarly:
> dbi:/dsnuri?dbi:... :-)
Well well. It's yet another layer on top of tnsnames.ora /
freetds.conf + odbc.init. Won't it be slow? How often you you actually
need that extra level of indirection?
If you have a project where you need to connect to the same data
sources from multiple scripts / application, how do you handle it with
DBI 1? I usually write my own module (App1::DBI) that only implements
function connect with certain default attributes. So that I then call
my $dbh = App1::DBI->connect('dbx');
and the App1::DBI looks up password for the user name 'dbx', uses DBI,
a calls DBI->connect with RaiseError => 1, AutoCommit => 0,
LongTrunc..., etc. set. How do other people handle this situation?
Will the driver manager help in this?
Honza Pazdziora | firstname.lastname@example.org | http://www.fi.muni.cz/~adelton/
.project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
Only self-confident people can be simple.