Christopher Petrilli wrote:
Christopher Petrilli wrote:
BTW, I didn't mean to imply that what you've done isn't useful, it's simply incompatible with the direction we're taking. This is somewhat discussed in my roadmap. If you'd like to maintain the interface that you're talking about, then that'd be excellent.
In what way is it incompatible ? mxODBC is DB API compliant in most parts and has lots of useful extensions such as the ODBC catalog functions. The interface itself is thread safe and thread friendly. Of course, whether a certain ODBC driver is depends on the driver.
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.
FYI, mxODBC currently works with these database drivers/managers: Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - Linux unixODBC Driver Manager - EasySoft ODBC Bridge - OpenLink ODBC drivers - Intersolv ODBC drivers + virtually any database supported by one of the listed ODBC managers.
The issue is more that in many cases (Oracle for example) ODBC is enormously slower than the native drivers. we've had people comment that it's something around an order of magnitude. Also, Oracle's ODBC drivers leak like the proverbial sieve.
The problem with Oracle is that the connection times are exorbitant. Once you are connected the performance is much better. Also there are several different drivers out there: the original one by Oracle, the one by MS included in their free ODBC driver kit, ones by OpenLink and InterSolv. 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.
Therefore we plan to target native interfaces, rather than glued on top constructs. Only on Windows is ODBC any form of gain. Now, if X/Open CLI is the native interface (as with DB2), then this will be fine... we just plan to talk to native interfaces.
FYI, Solid also uses ODBC as native interface. (BTW, I finally got the combo IBM DB2 / mxODBC to link without core dumps. Now I'll have to dive into configuring the DB2 database...) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 80 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/