[DB-SIG] DB-API 1.1

[Greg Stein (Exchange)]

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

-g

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
>