Re: [Zope-dev] Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
We are abandoning the use of DB-API interfaces for our own use simply because they have proven to be of little value in getting things running.
Why is that ? The DB API is intended to be of general use, how can Zope be so much different ?
In addition, their behavioral assumptions are sometimes quite incompatible with Zope requirements. Jim Fulton can better speak to this. We're now doing a more "thin shim" approach, and not going anywhere near the DB-API or SWIG.
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.
It's a combination of paradigm matching as well as the fact that DCOracle generates a HUGE number of support requests that we simply don't have the energy to deal with. Now, having said that, 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.
ODBC is not really all that bad -- at least not always. It gives you database flexibility and portability that no other standard has achieved over the years, not even the later ones pushed by MS.
We see X/Open CLI as the interesting target, rather than ODBC. ODBC is a derivative now, as opposed to the source. And for our needs, X/Open CLI provides everything except BLOB support. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
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
participants (2)
-
Christopher Petrilli -
Michel Pelletier