[DB-SIG] Next Version [was Re: Preparing statement API]

[Greg Stein]

Capability discovery of the underlying database is very database-specific.
We have not defined any functions like that.

Unlike ODBC, the DBAPI is actually intended to be something of a
least-common-denominator. Capabilities and extensions that are specific to
a database can be implemented by that specific database provider. Trying
to create an entirely generic API for database interaction is very tough,
and is beyond the scope of what most people would like to see. DBAPI
provides a minimum set of functionality and creates a very good level of
consistency between the different providers.

Cheers,
-g

On Fri, 28 Jan 2000, Frank McGeough wrote:

> Is there any notion in the dbi layer of the app discovering the capabilities
> of the driver as in the ODBC spec where I can do a SQLGetInfo call to find
> out some information about the driver? I just think it's awkward to throw
> exceptions for information that might be readily available and easily
> handled by the app.
> 
> ----- Original Message -----
> From: M.-A. Lemburg <mal@lemburg.com>
> To: <zen@cs.rmit.edu.au>
> Cc: Database SIG <db-sig@python.org>
> Sent: Friday, January 28, 2000 5:40 AM
> Subject: Re: [DB-SIG] Next Version [was Re: Preparing statement API]
> 
> 
> > Stuart 'Zen' Bishop wrote:
> > >
> > > On Thu, 27 Jan 2000, M.-A. Lemburg wrote:
> > >
> > > > Cool. I'll keep it in mind for the next version of the
> > > > DB API spec. BTW, are there any other things which should
> > > > be done for the next version ?
> > >
> > > Things I (as a user) would like to see:
> > >
> > >     Common call to enable/disable autocommit. Default would have to be
> > >     'driver specific' for compatibility. Drivers could simply throw
> > >     an exception if a programmer tries to set an unsupported mode.
> >
> > Hmm, not all DBs provide transactions and even those that
> > do sometimes have different thoughts about what isolation
> > level to choose as default.
> >
> > I don't think we'll ever have a common API for transaction
> > mechanisms... I guess this remains for the abstraction layer
> > to be implemented.
> >
> > >     A common parameter style supported by all drivers. Or a method
> > >     that convers 'generic' parameter style to 'paramstyle' parameter
> > >     style.
> >
> > Dito.
> >
> > >     Whatever additions Digital Creations requires to enable a Generic
> > >     ZopeDA to be written that supports all compliant Python Database API
> > >     drivers (well... drivers that don't throw an exception when
> > >     con.autocommit(0) is called).
> >
> > Note that as soon as you deal with DB managers such as ODBC
> > managers, you don't know about transaction capabilities of
> > a DB until you connect to it.
> >
> > Why does Zope rely on the DB doing transactions ? I thought it
> > had its own transaction mechanism ?
> >
> > --
> > Marc-Andre Lemburg
> > ______________________________________________________________________
> > Business:                                      http://www.lemburg.com/
> > Python Pages:                           http://www.lemburg.com/python/
> >
> >
> >
> > _______________________________________________
> > DB-SIG maillist  -  DB-SIG@python.org
> > http://www.python.org/mailman/listinfo/db-sig
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 

-- 
Greg Stein, http://www.lyra.org/