[DB-SIG] interogating C language drivers

James Northrup james_northrup@iridium.com
Thu, 18 Mar 1999 12:30:32 -0500


    you have presented a veritable shopping list of independant efforts to examine and coalesce into something like a least-common-denominator wrapper/capabilities-model.

seems very similar to the task of writing a configure script with autoconf, a series test/examine/remark iterations.
e.g. boolean capability_node=function named 'x' of module 'z' returns result 'y' with type 'y.type' with value 'y.value' given parameters p[...] with types p[...].type and
values p[...].value

as for performance issues of wrapper classes, I like the flexibility provided by python to interrogate a module and pass off a function pointer, if one decides to build a
structure of lean and mean <function at *pointer*> objects.  (These kind of performance enhancements wouldn't seem appropriate to an API specification in a scripting
language, just an idiom for use at an application level.  My goal is to reduce application maintenance overhead for using a dbms in production.)

Thanks for your input

p.s. the ending remarks below concerning ODBC are exactly what I hope can apply to db-api, in an out-of-the-box python base module.

"M.-A. Lemburg" wrote:

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