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