Re: Drivers and Data Source Names

------=_Part_13514_29706357.1128575124447
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 10/4/05, Tim Bunce <[email protected]> wrote:
>
> No comments on 'Assumptions and Principles', but I guess they weren't
> very controversial.
>
> Maybe this next chunk will be more so...



Yes - you got a jackpot.


=3Dhead1 Drivers
>
> Driver metadata should be accessible without loading db client api lib.
> That lets us cheaply and safely 'load' all drivers and at least query
> metadata.


As long as that is substantially automatic - the DBI provides a clear
framework and the driver merely fills in the details, I see no particular
problem with this.


Need more extensive driver metadata.
> Including which attributes a driver needs to connect - for UI.
>
> =3Dhead2 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.



Again, it sounds fine as long as DBI does most of the hard work. The driver
should merely need some clear rules on what it must do (and must not do) in
order to compliant/compatible with the DBI resources.


=3Dhead1 Data Source Names
>
> Data Source Names will be valid URIs (RFC 2396:
> http://www.faqs.org/rfcs/rfc2396.html).



Oh boy - the flak starts flying.


The "resource" being identified is a connection to a database or server
> instance
> along with optional connection attributes.
>
> =3Dhead2 "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.



The drive is common to all proposed URI's. In our previous protracted
discussions, I don't recall any other component that existed for every
driver. In particular, I note that not even a host is applicable to the ID
string for every DBMS (specific exception: Informix). As such, I think that
any system predicated on requiring a host name is flawed, and therefore the
'standard' RFC 2396 notation is not appropriate.

RFC 2396 suggests that the 'userinfo' portion should not contain clear-text
passwords, for sound operational security reasons.

Some generic and specific examples:
>
> dbi://host/driver/dbname
> dbi://foo.com/mysql/dbname


host does not apply to Informix servers - or, more accurately, it is
submerged behind a 'server name', which is an Informix Dynamic Server
instance name, not a host name. The server name does not have any
domain-based notation in it -- that is, the usual name is a string of simpl=
e
characters such as 'aleph_31'. If you decide that:

dbi://ids_servername/informix/dbname

is acceptable - no optional port number (or, if provided, the port number
will be ignored), and part of the database name appears before the driver
and part appears afterwards (the natural notation would be
dbname@ids_servername),
then I suppose I can live with it. It is inelegant, but that has always bee=
n
the case with DBI connection strings. The only part of DBI v1 DSN that I'd
consider changing is standardizing on is the username and password; it woul=
d
be more symmetric if they were standardized attributes embedded in the DSN;
it is not wholly clear that this is a good idea since the DSNs are likely t=
o
passed around and that might reveal passwords.

I know there are ardent advocates for complex DSN schemes that work for a
few DBMS - but I've not seen one that works for all DBMS without forcing
undue contortions on some drivers.

dbi:/driver/dbname #assumes localhost unless driver and dbname imply
> otherwise
> dbi:/Oracle/TNSNAME



Surely, that should be: dbi:///Oracle/TNSNAME?

In HTTP URIs, for example, having nothing between the double slash and the
leading component of the path (hence triple slash) means the local host.
Maybe Informix URI's are always local host URI's:
dbi:///Informix/dbname@ids_servername (or the escaped version:
dbi:///Informix/dbname%40ids_servername).

dbi://user:pass@host:port/dbtype;driver-params/dbname;connection-params
>
> dbi://fred:[email protected]:1234/mysql;foo=3Dbar/testdb;AutoCommit=3D0;mysql_=
bop=3Dauto


What's the distinction between foo=3Dbar and AutoCommit=3D0; why does one a=
ppear
after the driver and the other after the dbname?


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



dbi:///SQLite/...

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.)


If the 'other uses' are DBI properties, then I guess that's your
prerogative.

=3Dhead2 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.



dbi:///Proxy/...what goes here for the DBI Proxy driver...?

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.
>

How does dbi:sales fit into RFC 2396?


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


dbi:///dsnuri?...


The 'dsnuri' driver could open the ~/.dbi-dsn.txt text file and read the DB=
I
> 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:... :-)
>
> =3Dhead2 Connection Pooling
>
> Driver managers will also be where connection pooling is implemented (or
> at
> least, abstracted).
>
> =3Dcut
>

Is a driver told about the host and portname (and userinfo) parts of the
URI? If so, does the driver get to object if they're provided and it doesn'=
t
like them - so the Informix (and SQLite?) drivers can say "every database
must be treated as a local database" -- dbi:///Informix/dbname and
dbi:///SQLite/%2Fpath...

If DBI doesn't pass that information to the driver, what does it do with it=
?

How will the username and password be handled in general? With separate
arguments, as now? What about if they're provided in the userinfo of the
URI? What if they're provided in both places? Can username and password
(actually, they'd be Username or Username and Password) be standard DBI
connection attributes like AutoCommit (that's a change I'd have no qualms
about appearing in DBI v1, though there's no real virtue in making the
change right now)?

--
Jonathan Leffler <[email protected]> #include <disclaimer.h>
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
"I don't suffer from insanity - I enjoy every minute of it."

------=_Part_13514_29706357.1128575124447--