[DB-SIG] interogating C langauge drivers

M.-A. Lemburg mal@lemburg.com
Thu, 18 Mar 1999 10:19:31 +0100

James Northrup wrote:
> As I have tussled about in this sig it occurs to me none have yet spoken from the standpoint of building a kernel or drivers for n*m devices.  Everyone wants to write a
> driver that conforms, only does it better than the spec.  So many creative endeavors.
> As time permits, I shall build a pure python module that performs the task of interrogating modules (or driver, hereafter).

Andy Dustman's approach has much of this flexibility: it provides
a core database C level wrapper and then extends it using a normal
Python class to fit the DB API. You can then subclass it, etc.

Note that it is also easily possible to put an abstraction layer on top
of the DB API definitions to have the subclassing feature for
all interface modules out there (and to possibly fix some DB specific
quirks). But things tend to get slower with every layer, so this
may not be an option to suit everyone.

> These drivers it interrogates will belong to a registry.  The user will "register" drivers at runtime.
> The interrogation results shall provide a driver-capability model for each subject driver.
> These driver capabilities shall be fashioned directly after the [DB-SIG] annotated 1.1 spec. (initially)
> As this undertaking nears completion, I will gladly offer this small bit of purpose-written abstraction into a larger base of usage and support.

Note that ODBC already offers such a flexible setup. You use
one of the available Python interfaces (win32's odbc, mxODBC,
Sam Rushing's calldll odbc wrapper or DC's swigged ODBC) and
then leave the driver part to the system administrator.

It's how I am working in production and so far I have managed
quite well (let aside the memory leakage problems that occur
with some ODBC drivers).

Marc-Andre Lemburg                               Y2000: 288 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :