Greg Stein (Exchange) gstein@exchange.microsoft.com
Sun, 14 Jun 1998 20:42:06 -0700

#2: the intent of the dbi module was that only one version existed on the
planet. e.g. the db-sig itself owns it and the module implementors reference
it, but don't redefine it.


p.s. some later emails discussed dictionaries being passed to Connect(). I'd
like to point out that this becomes difficult for the user to specify in a
one-liner. Keyword args is pretty nice, but a bitch and a half to deal with
from the C side of things. Allowing a database-defined set of args or a
string is easiest on the module implementor. This variance between Connect()
calls is also the reason that Michael Lorton specified that the import and
connection to a database is specific, while the rest of the API can be
generic; therefore, the use of the module name as the connection function.
[ it is assumed as a fact that each database has different parameter sets
and definitions for a connection. ]

> -----Original Message-----
> From: M.-A. Lemburg [mailto:mal@lemburg.com]
> Sent: Thursday, May 21, 1998 2:59 AM
> To: DB-SIG @ Python.org
> Subject: [DB-SIG] DB-API 1.1
> I'd like to start discussing updating/extending the DB-API 1.0 to
> a new version. IMHO, this needs to be done to
> 	a. clearify a few minor tidbits
> 	b. enable a more informative exception mechanism
> You can have a look at an alpha version of 1.1 at:
> 	http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html
> Major additions are the new dbi-exception classes (which use the
> 1.5 class exception mechanism, thus allowing to catch all DB-related
> exceptions with the Error-base class, or just a specific subclass
> of it), .nextset() and a few statements about the return values
> of the .fetch*() methods in case there's nothing left to be fetched.
> Some other suggestions:
> 1. Instead of defining the connection constructor to be named
>    <modulename>, I think Connect(...) is a better choice 
> (helps porting
>    applications from one DB to another.
> 2. We should come up with a reasonable package structure for database
>    access, e.g. to give the discussion a starting point:
> [Database]
> 	[<name of database>]
> 		[dbi]
> 	[<name of database>]
> 		[dbi]
> You'd then write:
> from Database.Oracle import *
> db = Connect('...')
> c = db.cursor()
> c.execute('...',dbi.dbiDate(...))
> When porting to another database, only 'Oracle' would have to changed
> to the other DBs name (in the ideal case ;-).
> 3. cursor.description should be well defined, always return 7-tuples,
>    but allow None to be passed as synonym for 'data not available'.
> 4. Fix some standard for date/time values. I won't comment,
>    since I am a little biased on this one ;-)
> Awaiting your comments.
> -- 
> Marc-Andre Lemburg
> ----------------------------------------------------------------------
>              | Python Pages:  http://starship.skyport.net/~lemburg/  |
>               -------------------------------------------------------
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig