[DB-SIG] SQL PEP for discussion

Federico Di Gregorio fog@mixadlive.com
17 Jun 2001 16:37:56 +0200

personally i am quite against such a wrapper. here are some critics...

On 17 Jun 2001 23:47:42 +1000, Stuart Bishop wrote:
>     Python previously defined a common relational database API that
>     was implemented by all drivers, and application programmers
>     the drivers directly. This caused the following issues:
>       It was difficult to write code that connected to multiple
>       database vendor's databases. Each seperate driver used defined
>       its own heirarchy of exceptions that needed to be handled, and
>       similar problems occurred with identifying column datatypes etc.

DBAPI specifies how column datatypes should be treated and identified.

>       Platform independant code could not be written simply,
>       due to the differing paramater styles used by bind variables.
>       This also caused problems with publishing example code and
>       The API remained minimal, as any new features would need to
>       be implemented by all driver maintainers. The DB-SIG felt
>       most feature suggestions would be better implemented by higher
>       level wrappers, such as that defined by this PEP.

but this pep does not define an higher level or meny new features. 90%
of the api is a re-definition of the stuff in the DBAPI documenti.

>       More than a few people didn't realise that Python _had_ a
>       API, as it required people to find the DB-SIG on python.org.

so lets make the DB-SIG and the dbapi document more visible. you won't
sole the problem by adding yet another layer.

>     The wrapper will ease writing RDBMS independant code:
>       The wrapper will enforce thread safety. It is unknown at this
>       if this will be done by passing calls to a single worker thread
>       non thread safe drivers, or by raising an exception if an
>       is made to use a driver in a unsafe manner.

if you're awriting a multithreaded application, your code is only part
of the whole. you need to think carefully about the db, the driver, etc.
if you really *need* multithreading independant code is the last of your

>       The driver name is passed to the connect method as a string,
>       rather than importing the driver module, to allow the driver
>       used by an application to be defined in a configuration file or
>       other resource file.

no need for that. look at the (preliminary) test suite in psycopg and
how you can give it the name of the module to be loaded on the command
line. it a three-liner...

>       Bound parameters are specified in a common format, and
>       to the native format used by the driver.

this *is* usefull, but you don't need to completely reimplement the
dbapi for that. just a couple of functions will do it.

>       Some basic guidelines on writing RDBMS independant code will
>       be provided in the documentation (this is not always obvious
>       to developers who only work with one vendor's database system).

my main concern is that rdbms independant code is not that much
important as you say. defferent db have different features and only the
most basic application uses a common subset of sql. when you write an
application, choosing the right db, is an integral part of the
development process. the dbapi is there for, imho, the developer being
able to switch from db to another without haveing to re-learn a
completely new api, not for automagically porting applications froma db
to anothr. porting an application always involves some work and changing
a couple of sql statements or some function calls is not the worse part
of the process.

anyway, a wrapper with some utility functions is, imho, a very good
idea. things *really* db independent like a function that transform any
bound parameters to a particular format and such. i'll call it
sqlutils.py, though.


Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
              All programmers are optimists. -- Frederick P. Brooks, Jr.