[Zope] zope da's

[Christopher Petrilli]

On 12/15/99 4:46 PM, George Runyan at grunyan@emerging.com wrote:

> why does zope use specific DA's instead of a common bridge like JDBC? I was
> apart of a web logic presentation a few weeks ago and alot of the developers
> liked the fact that a) they rewrote the socket/rmi api (it multiplexes n
> requests over a single socket), b) jdbc (of course!) exists and we could
> 'move this from platform to platform' and not break anything, c) scalability
> and clustering methods (they use master/slave stubs) which seems to be much
> more complex than ZEO- but it load balances at the service layer.  any
> comments?  

Well, first off, JDBC is Java-specific, hence Java Data Base Connection :-)
That makes it of no use for anything not written in Java.  RMI is the same
thing.  The question, however, is similar to the one asked vis-a-vis using
ODBC v. native drivers, and I'll frame it that way.

The major advantage of using ODBC from an application perspective is that
you gain some level of "independence" from a specific database, allowing you
to move from Access to SQL Server to DB2 as you change requirements.  This
is of course a "red herring," in that there is more to databases than just
the adapter you talk to.  SQL syntax can change dramatically, things like
stored procedures, BLOB support, etc., are hugely different and ODBC doesn't
deal with that.  We tried using Access to prototype databases on the desktop
that were going to go to Oracle/Sybase at some point, and found that most
things broke because of simple differences.

Having said that, we do provide this abstraction, which is that the
Connection object is the only thing dependent on the database.  SQLMethods
are not dependent on the database under them unless you choose to make them.
Unfortunately, the world isn't nearly as "standards based" as people would
like you to believe.

So assuming you buy into the "advantage," why would you forsake this panacea
for the nightmare of "database specific" adapters?  Well, one it lets you
gain better performance by removing at least one layer of code off the
system.  Second, ODBC (and JDBC) are least common denominators, and while
they provide some level of abstraction, often it's missing core pieces that
people would like to use.  Additionally, ODBC drivers on anything but NT are
not common, often extra-cost and largely unused, therefore potentially
buggy, and therefore we'd be forsaking the entire UNIX arena (which
represents most of our customer base) by buying into what is effectively a
Windows strategy.

Also, on platforms like Oracle, the ODBC drivers are notoriously bad.
 
> but I am interested in the jdbc vs. custom built DA's

This is just my view, but the JDBC comparison is not terribly viable given
we don't use Java. 

Chris
-- 
| Christopher Petrilli        Python Powered        Digital Creations, Inc.
| petrilli@digicool.com                             http://www.digicool.com