[Zope-dev] Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA

[Michel Pelletier]

Christopher Petrilli wrote:

> >
> > Oh well, then I guess you're on your own. I would have rather liked
> > to see more native DB-API style interfaces appear than incompatible
> > thin layer new ones.
> 
> the design we use (which is a
> thin shim of C with 99% in Python) is entirely usable for writing a DB-API
> layer on TOP of, we simply have no value in that right now.  This doesn't
> mean that some enterprising individual couldn't write one and support it
> themselves.

This is sort of the main point, we are not really anti-DBI (ok, *I'm*
not, but I probably haven't work with it enough to apreciate/loath it). 
But rather we prefer to see a thin wrapping of a C library first, *then*
write a DBI compliant layer.  This gives a few leveredge points:

1) it's *far* easier to 'thin' wrap a few C functions than to engineer
an entire DBI compliant module in C (I believe other DBI modules work
this way, ie, on top of a simple C wrapper).  A good example from my
experience is the ctsybasemodule.  I'm sure the author put much effort
into it, but it's buggy, which isn't a big deal if it also wasn't
undocumented and completely abandoned by it's original author.  Given
that it also leaks in several places, is not threadsafe, does not handle
error conditions well, and has some other minor issues, we decided to
write our own thin wrapper around the sybase ctlib.  It took us (ok,
Jim) as long to wrap the ctlib as it did for us to just 'discover' all
the problems in ctsybasemodule.  Since we support Zope+Sybase, we needed
much better control over the situation.  Now, given the very nice and
clean wrapper around the ctlib, a DBI compliant module can be written
very easily in Python, probably far less buggy etc.  I'm sure I don't
have to convince anyone here about the advantages of writing Python over
C (or the disadvantages, which I don't think apply in this case).

2)  Our needs, ie, database adapters for Zope, do not need most of the
DBI spec, so we engineered lower level tools that *can* be used to write
a DBI compliant module, but also clear up alot of our code and allow us
to have a better grasp of the whole system for debugging purposes
(debugging C modules gives me nightmares).  DBI is also a solution to a
different problem than we have.  Much of DBI features are (IMO) there to
provide a programmer with python level methods to use relational
databases.  Since Zope abstracts all of this out to the user with
database connections and ZSQL methods, most of the DBI interface is not
needed by us.  For example, transactions, which DBI gives you methods to
work with, are handled completely by Zope's transaction manager, the
Zope programmer need not know anything about them unless they step down
into the guts of Zope's multi-database transaction manager.

anyways, this isn't really meant to start a religeous war, just to clear
up where we stand.  I've never used ODBC anything, so I could be just
waving my hands alot here.

-Michel