Re: Drivers and Data Source Names

While I'm as nervous as some of the others about making the connect 
strings harder to parse, the thing that is my number two peeve about DBI 
is that this parsing isn't done for me.

Where is my DBI::DSN object, that contains the connect information and 
that I can serialize and deserialize easily. Something I can validate as 
a connect string BEFORE I actually have to use it.

I'd bet that people have had to implement this over and over again 
themselves. Many of the issues about connect strings being hard to parse 
go away if DBI2 gives us a DSN class that does it for us, and does it 
for every driver regardless of whether or not it is installed. Even if 
it can't know all the details, it should at least know what typeof 
driver it is, etc.

Give me a usable and validatable DSN object, and you can do 
whatever-the-hell you like with the format, because then the entire 
problem of parsing it gets solved once and by the same person defining 
the format.

Adam K

> =head2 "dbi:" Scheme URI Structure
> 
> Exact scheme structure to be determined but will conform to the "generic URI"
> format and so can be manipulated effectively using modules like URI
> L<http://search.cpan.org/~gaas/URI/URI.pm#GENERIC_METHODS>
> This includes the use of per-segment path parameters - see section 3.3 of the RFC.
> 
> Some generic and specific examples:
> 
> 	dbi://host/driver/dbname
> 	dbi://foo.com/mysql/dbname
> 
> 	dbi:/driver/dbname   #�assumes localhost unless driver and dbname imply otherwise
> 	dbi:/Oracle/TNSNAME
> 
> 	dbi://user:pass@host:port/dbtype;driver-params/dbname;connection-params
> 	dbi://fred:[email protected]:1234/mysql;foo=bar/testdb;AutoCommit=0;mysql_bop=auto
> 
> 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:
> 
> 	dbi:/SQLite/%2Fpath%2Fto%2Ffile
> 
> but that's hardly friendly, so there's a possible alternative form:
> 
> 	dbi:/SQLite/&?/path/to/file
> 
> or, as the file path logically corresponds to the host:port portion:
> 
> 	dbi://&/SQLite?/path/to/file
> 
> Here the "&" character represents whatever is in the query portion of the URI.
> But that's just a handy shorthand for humans, not the canonical form.
> Non-trivial DSN URIs should be constructed using the URI module, or similar.
> 
> I'm trying to avoid using the 'obvious' forms:
> 
> 	dbi:/SQLite/absolute/path/to/file     # no
> 	dbi:/SQLite/./relative/path/to/file   # no
> 
> because I want to reserve further levels of the URI path component for other uses.
> (Though it partly depends on how the driver nesting/wrapping issue gets resolved.)
> 
> =head2 Indirection
> 
> 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:
> 
> 	dbi:/dsnuri?file:~/.dbi-dsn.txt#myname
> 
> 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?http://...
> 	dbi:/dsnuri?dbi:...         :-)
> 
> =head2 Connection Pooling
> 
> Driver managers will also be where connection pooling is implemented (or at
> least, abstracted).
> 
> =cut