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

[M.-A. Lemburg]

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/