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

M.-A. Lemburg mal@lemburg.com
Sat, 29 Jan 2000 11:40:46 +0100

Stuart 'Zen' Bishop wrote:
> On Fri, 28 Jan 2000, Greg Stein wrote:
> > Capability discovery of the underlying database is very database-specific.
> > We have not defined any functions like that.
> I understand this, and have not suggested anything that is particularly
> RDBMS specific.
> A common parmstyle could easily be faked with regular expressions (although
> I agree this would be best left up to a higher abstraction layer - perhaps
> a db library included with a future python distribution).
> At the moment, an autocommit mode _cannot_ be handled at a higher abstraction
> layer by checking for the existance of the rollback method and explicitly
> calling commit after every transaction if autocommit mode is on. For reasons
> why, have a look at footnote 3 of the API. Perhaps the addition of a module
> global 'transactionsupport'.
>     0 - No rollback
>     1 - rollback to last commit

While this would help, it is not needed. All you have to do is
check whether the connection object has the .rollback() method
and if it does, whether it works:

def haveTransactions(conn):
    if not hasattr(conn,'rollback'):
	return 0
	return 0
	return 1

The function has to be called on newly created connection objects
to not cause unwanted .rollbacks().

> Higher integers would be used if the API ever supports more advanced
> transaction mechanisms (are any of these standard?). This module global
> cannot be assumed to be a constant, on account of the 'dynamically configured
> interfaces' mentioned in footnote 3. Not that I can think of any that exist :-)
> Could we have a Footnote stating that a higher level abstraction layer
> is envisaged to add functionality such as:
>     autocommit
>     generic parameter style
>     minimum thread safety (?)
>     advanced row retrieval (rows returned as dictionary or user specified
>     class)
>     other frequent requests as approved :-)
> BTW - is anyone working on this, or should I sketch out an API for
> general mirth and ridicule?

Such a higher level layer written in Python would indeed be nice.
It should ideally focus on an OO-style representation of DB
access similar to the RogueWave OO-layer on top of JDBC... well,IMHO
anyway ;-)

> > 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.
> Its not too tough though, as we have the advantages of being able to
> steal ideas from Perl's DBI which has been in production for ages now,
> as well as the advantages of Python (exception handling makes an interface
> like this sooo much cleaner).

Perhaps someone could summarize these features in Perl's DBI or
provide pointers ?! I, for one, don't have any experience with Perl's

Marc-Andre Lemburg
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/