From gherman@darwin.in-berlin.de Tue Oct 5 17:58:22 1999 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Tue, 05 Oct 1999 18:58:22 +0200 Subject: [DB-SIG] RE: Oracle Module for win32?? References: <199909220512.BAA19021@python.org> Message-ID: <37FA2E2E.B53B7F98@darwin.in-berlin.de> "Risney, Marc S" wrote: > > Hey Pythoneers, > > I am attempting to work with Digitalk Creations DCOracle , but > cannot get it to compile, > does anyone please have a compiled .pyd or a decent Oracle module > please help.. Try http://starship.python.net/crew/gherman/potpurri/dcoracle/ This was kindly compiled by Christian Tismer and is working fine for me with Oracle 7.3.4. But it is not the newest version (1.3.0). Regards, Dinu -- Dinu C. Gherman ................................................................ "An average of more than 15 % of adults in 12 industrialized countries are functionally illiterate; in Ireland, the United Kingdom and the United States, the rates are over 20 %." (The State of the World's Children 1999, UNICEF, http://www.unicef.org/sowc99) From petrilli@amber.org Tue Oct 5 18:54:02 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 5 Oct 1999 13:54:02 -0400 Subject: [DB-SIG] RE: Oracle Module for win32?? In-Reply-To: <37FA2E2E.B53B7F98@darwin.in-berlin.de> References: <199909220512.BAA19021@python.org> <37FA2E2E.B53B7F98@darwin.in-berlin.de> Message-ID: <19991005135402.A4803@trump.amber.org> Dinu C. Gherman [gherman@darwin.in-berlin.de] wrote: > "Risney, Marc S" wrote: > > > > Hey Pythoneers, > > > > I am attempting to work with Digitalk Creations DCOracle , but > > cannot get it to compile, > > does anyone please have a compiled .pyd or a decent Oracle module > > please help.. > > Try > > http://starship.python.net/crew/gherman/potpurri/dcoracle/ > > This was kindly compiled by Christian Tismer and is working fine > for me with Oracle 7.3.4. But it is not the newest version (1.3.0). Since I did all the changes for the new version, the only things of any interest would be: o Statement handles o Bugs in LONGRAW/BLOB support :-) Chris -- | Christopher Petrilli | petrilli@amber.org From jim@digicool.com Tue Oct 5 18:24:28 1999 From: jim@digicool.com (Jim Fulton) Date: Tue, 05 Oct 1999 17:24:28 +0000 Subject: [DB-SIG] RE: Oracle Module for win32?? References: <199909220512.BAA19021@python.org> <37FA2E2E.B53B7F98@darwin.in-berlin.de> <19991005135402.A4803@trump.amber.org> Message-ID: <37FA344C.FACA0A32@digicool.com> Christopher Petrilli wrote: > > Dinu C. Gherman [gherman@darwin.in-berlin.de] wrote: > > "Risney, Marc S" wrote: > > > > > > Hey Pythoneers, > > > > > > I am attempting to work with Digitalk Creations DCOracle , but > > > cannot get it to compile, > > > does anyone please have a compiled .pyd or a decent Oracle module > > > please help.. > > > > Try > > > > http://starship.python.net/crew/gherman/potpurri/dcoracle/ > > > > This was kindly compiled by Christian Tismer and is working fine > > for me with Oracle 7.3.4. But it is not the newest version (1.3.0). > > Since I did all the changes for the new version, the only things > of any interest would be: > > o Statement handles > o Bugs in LONGRAW/BLOB support Of even more interest is the fact that these were Python, not C changes. So, the extension module posted on starhip may be current. To be sure, compare the RCS Id strings in the pyd files with the Id strings in the latest sources. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From als@turnhere.com Tue Oct 5 19:35:12 1999 From: als@turnhere.com (alexander smishlajev) Date: Tue, 05 Oct 1999 21:35:12 +0300 Subject: [DB-SIG] RE: Oracle Module for win32?? References: <199909220512.BAA19021@python.org> <37FA2E2E.B53B7F98@darwin.in-berlin.de> Message-ID: <37FA44E0.B435EB89@turnhere.com> "Dinu C. Gherman" wrote: > > "Risney, Marc S" wrote: > > > > I am attempting to work with Digitalk Creations DCOracle , but > > cannot get it to compile, > > does anyone please have a compiled .pyd or a decent Oracle module > > please help.. > > http://starship.python.net/crew/gherman/potpurri/dcoracle/ > > This was kindly compiled by Christian Tismer and is working fine > for me with Oracle 7.3.4. But it is not the newest version (1.3.0). two weeks ago i have successfully compiled DCOracle 1.3.0 with Python 1.5.2 and Oracle 8.0.4. i am not using all of the DCOracle features (procedure extensions, array bindings, LOBs etc.), but basic select/insert/update operations seem to work ok. i have already informed Marc S Risney about that, and if anyone else needs win32 binaries, i will be glad to send the package. best wishes, alex. From akuchlin@mems-exchange.org Mon Oct 11 21:42:23 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Mon, 11 Oct 1999 16:42:23 -0400 (EDT) Subject: [DB-SIG] Prototype Zope mxODBC DA Message-ID: <199910112042.QAA20019@amarok.cnri.reston.va.us> Last week we switched our development server from Zope 1 to Zope 2, and found that it broke the old Solid database adapter. SELECTs worked up, but operations that changed the database left an open transaction dangling. Today I set about trying to turn the Z Oracle Database Adapter into a DA for the mxODBC package. It proved unexpectedly simple, and the results seem to be working fine. (Is there a test suite or test procedure that I could use to verify the level of compliance. ZOracleDA is Level 3 compliant, according to http://www.zope.org/Members/petrilli/DARoadmap; I don't know if the mxODBC DA is too.) The changes to the Z Oracle DA are: * Blow away the src/ and DCOracle subdirectories; I've assumed that mxODBC is already installed. * mxODBC wants mxDateTime, which uses the package name 'DateTime'. This conflicts with Zope's DateTime package. The fix, luckily, is simple: edit mxDateTime.h in the Solid subdirectory of mxODBC, to import mx.DateTime, and install mxDateTime accordingly. * Apply the patches below. The bulk of the patch is just simple renaming; the only real changes are to import ODBC.Solid, to parse apart the connection string (mxODBC wants three arguments, not just a single string). Outstanding bugs: the icon for the DA object is broken, and I can't figure out why, and the database browser still doesn't work. Anyway, the next step is to make the mxODBC DA not dependent on Solid, but capable of using Adabas or any other database supported by mxODBC. Question for Christopher Petrilli: because the patches from the Oracle DA are so small, does merging the mxODBC and Oracle DAs into one code base seem feasible? Follow-ups set to zope-dev@zope.org. -- A.M. Kuchling http://starship.python.net/crew/amk/ Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your home. -- Terry Pratchett & Neil Gaiman, _Good Omens_ diff -r -C2 ZOracleDA/DA.py mxODBCda/DA.py *** ZOracleDA/DA.py Fri Jan 15 14:36:09 1999 --- mxODBCda/DA.py Mon Oct 11 16:18:30 1999 *************** *** 95,99 **** # ############################################################################## ! database_type='Oracle' __doc__='''%s Database Connection --- 95,99 ---- # ############################################################################## ! database_type='mxODBC' __doc__='''%s Database Connection *************** *** 107,113 **** from ExtensionClass import Base ! manage_addZOracleConnectionForm=HTMLFile('connectionAdd',globals()) ! def manage_addZOracleConnection(self, id, title, connection_string, check=None, REQUEST=None): --- 107,113 ---- from ExtensionClass import Base ! manage_addZmxODBCConnectionForm=HTMLFile('connectionAdd',globals()) ! def manage_addZmxODBCConnection(self, id, title, connection_string, check=None, REQUEST=None): *************** *** 138,151 **** folder_methods={ ! 'manage_addZOracleConnection': ! manage_addZOracleConnection, ! 'manage_addZOracleConnectionForm': ! manage_addZOracleConnectionForm, } __ac_permissions__=( ! ('Add Z Oracle Database Connections', ! ('manage_addZOracleConnectionForm', ! 'manage_addZOracleConnection')), ) --- 138,151 ---- folder_methods={ ! 'manage_addZmxODBCConnection': ! manage_addZmxODBCConnection, ! 'manage_addZmxODBCConnectionForm': ! manage_addZmxODBCConnectionForm, } __ac_permissions__=( ! ('Add mxODBC Database Connections', ! ('manage_addZmxODBCConnectionForm', ! 'manage_addZmxODBCConnection')), ) diff -r -C2 ZOracleDA/__init__.py mxODBCda/__init__.py *** ZOracleDA/__init__.py Fri Jan 15 13:09:48 1999 --- mxODBCda/__init__.py Mon Oct 11 15:12:29 1999 *************** *** 95,99 **** # ############################################################################## ! __doc__='''Generic Database Adapter Package Registration $Id: __init__.py,v 1.3 1999/01/15 18:09:48 jim Exp $''' --- 95,99 ---- # ############################################################################## ! __doc__='''mxODBC Database Adapter Package Registration $Id: __init__.py,v 1.3 1999/01/15 18:09:48 jim Exp $''' diff -r -C2 ZOracleDA/browse.dtml mxODBCda/browse.dtml *** ZOracleDA/browse.dtml Fri Jan 15 13:00:58 1999 --- mxODBCda/browse.dtml Mon Oct 11 16:17:25 1999 *************** *** 4,8 **** ! <!--#var Type--> --- 4,8 ---- ! <!--#var Type--> diff -r -C2 ZOracleDA/connectionAdd.dtml mxODBCda/connectionAdd.dtml *** ZOracleDA/connectionAdd.dtml Fri Jan 15 13:00:58 1999 --- mxODBCda/connectionAdd.dtml Mon Oct 11 16:17:54 1999 *************** *** 1,9 **** ! Add Z Oracle Database Connection !

Add Z Oracle Database Connection

!
--- 1,9 ---- ! Add Z mxODBC Database Connection !

Add Z mxODBC Database Connection

!
*************** *** 11,15 **** --- 11,15 ---- *************** *** 18,22 **** --- 18,22 ---- *************** *** 47,52 ****

! The connection string used for Z Oracle Database Connection ! are exactly the same connection strings required by Oracle tools. The connection strings are typically of the form: 

--- 47,52 ----
  

  

!     The connection string used for Z mxODBC Database Connections
!     vary depending on the database being used.
      The connection strings are typically of the form:
  
diff -r -C2 ZOracleDA/db.py mxODBCda/db.py
*** ZOracleDA/db.py	Fri Aug 20 10:47:44 1999
--- mxODBCda/db.py	Mon Oct 11 16:27:41 1999
***************
*** 99,108 ****
  __version__='$Revision: 1.5 $'[11:-2]
  
! import DCOracle, DateTime
! DCOracle.dbi.dbiDate=DateTime.DateTime
  from Shared.DC.ZRDB.TM import TM
  
  import string, sys
! from string import strip, split, find
  from time import time
  
--- 99,109 ----
  __version__='$Revision: 1.5 $'[11:-2]
  
! import ODBC.Solid
! dbModule = ODBC.Solid
! 
  from Shared.DC.ZRDB.TM import TM
  
  import string, sys
! from string import strip, split, find, join
  from time import time
  
***************
*** 115,124 ****
      _p_oid=_p_changed=_registered=None
  
!     Database_Connection=DCOracle.Connect
!     Database_Error=DCOracle.error
  
      def __init__(self,connection):
          self.connection=connection
!         db=self.db=self.Database_Connection(connection)
          self.cursor=db.cursor()
  
--- 116,130 ----
      _p_oid=_p_changed=_registered=None
  
!     Database_Connection=dbModule.Connect
!     Database_Error=dbModule.error
  
      def __init__(self,connection):
          self.connection=connection
!         # XXX this is really only correct for Solid
!         L = split(connection)
!         connstr = join(L[0:3], ' ')
!         user = L[3] ; password=L[4]
!         db=self.db=self.Database_Connection(connstr, user, password)
! #        db=self.db=self.Database_Connection(connection)
          self.cursor=db.cursor()
  
***************
*** 127,134 ****
  
      def _finish(self):
!         self.db.execute('commit')
  
      def _abort(self):
!         self.db.execute('rollback')
          
      def str(self,v, StringType=type('')):
--- 133,140 ----
  
      def _finish(self):
!         self.db.commit()
  
      def _abort(self):
!         self.db.rollback()
          
      def str(self,v, StringType=type('')):
***************
*** 152,159 ****
  
      def tables(self, rdb=0,
!                _care=('TABLE', 'VIEW')):
          r=[]
          a=r.append
!         for name, typ in self.db.objects():
              if typ in _care:
                  a({'TABLE_NAME': name, 'TABLE_TYPE': typ})
--- 158,167 ----
  
      def tables(self, rdb=0,
!                _care=('BASE TABLE', 'VIEW')):
          r=[]
          a=r.append
!         try: r=c.execute('select table_name, table_type from sys_tables')
!         except: return ()
!         for name, typ in c.fetchall():
              if typ in _care:
                  a({'TABLE_NAME': name, 'TABLE_TYPE': typ})



From petrilli@digicool.com  Mon Oct 11 21:48:59 1999
From: petrilli@digicool.com (Christopher Petrilli)
Date: Mon, 11 Oct 1999 16:48:59 -0400
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
Message-ID: <199910112049.QAA07701@python.org>

> Question for Christopher Petrilli: because the patches from the Oracle
> DA are so small, does merging the mxODBC and Oracle DAs into one code
> base seem feasible?

No, mostly because both are on the cusp of going somewhere else.  We will
most likely be undertaking a ground-up rewrite of the ODBC driver based
purely on the X/Open CLI spec (which is part of SLQ99), which will also be
used to talk to DB2.  This will not use a DB-API compatible interface for
various reasons.

Eventually the DCOracle adapter will undergo a similar transition.  We need
things that the DB-API doesn't provide, nor perhaps should it.  We have
already had great success with a Sybase adapter done this way (eventually to
be released).

Chris

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


From petrilli@digicool.com  Mon Oct 11 22:29:08 1999
From: petrilli@digicool.com (Christopher Petrilli)
Date: Mon, 11 Oct 1999 17:29:08 -0400
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
Message-ID: <199910112130.RAA09227@python.org>

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.

As for thread-safety, this would require more complete understanding, and
having never used mxODBC, I can't speak to its safety (which is also
dependent on the drivers).

Note that mxODBC has an incompatible license to ours.

Chris


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


From adustman@comstar.net  Tue Oct 12 02:56:42 1999
From: adustman@comstar.net (Andy Dustman)
Date: Mon, 11 Oct 1999 21:56:42 -0400 (EDT)
Subject: [DB-SIG] ANNOUNCEMENT: MySQLdb-0.1.1 released
Message-ID: 

MySQLdb-0.1.1 is a bugfix release for MySQLdb, a thread-friendly interface
to MySQL-3.22. Thanks to Stephen Gava and Mark Favas for pointing out a
few problems. cursor.fetchmany() now works (one I never used) and some of
the _mysql.conn methods probably would have dumped core if they were ever
used (MySQLdb doesn't use them, but they are there for completeness), and
didn't compile on some systems.

Thilo Mezger pointed out the patched ZMySQLDA didn't return numbers on
numeric columns; I had assumed that Zope did this conversion itself.
Adding the minimal type converter dictionary from MySQLdb to the connect()
call fixes this, and my understanding is that this means it is now really
working 100%.

As usual, it's available at http://starship.python.net/crew/adustman, and
will soon be on www.zope.org as well.

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d







From mal@lemburg.com  Mon Oct 11 22:35:31 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Mon, 11 Oct 1999 23:35:31 +0200
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
References: <199910112049.QAA07701@python.org>
Message-ID: <38025823.3A0D0E76@lemburg.com>

Christopher Petrilli wrote:
> 
> > Question for Christopher Petrilli: because the patches from the Oracle
> > DA are so small, does merging the mxODBC and Oracle DAs into one code
> > base seem feasible?

What mxODBC DA are you referring to here ? Is there something I've
missed ?
 
> No, mostly because both are on the cusp of going somewhere else.  We will
> most likely be undertaking a ground-up rewrite of the ODBC driver based
> purely on the X/Open CLI spec (which is part of SLQ99), which will also be
> used to talk to DB2.  This will not use a DB-API compatible interface for
> various reasons.
> 
> Eventually the DCOracle adapter will undergo a similar transition.  We need
> things that the DB-API doesn't provide, nor perhaps should it.  We have
> already had great success with a Sybase adapter done this way (eventually to
> be released).

Note that mxODBC does already link against the Linux ODBC driver
of IBM's Universal Database (DB2). It's just that the dynamic
load doesn't work due to some obscure compiler or linker bug, at
least not on my machine using the latest beta code from IBM (haven't
yet received the final product CD).

Chris, could you elaborate a bit on what features you need that are
not included in the DB API Spec ?

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    81 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From mal@lemburg.com  Tue Oct 12 09:20:00 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 12 Oct 1999 10:20:00 +0200
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
References: <199910112130.RAA09227@python.org>
Message-ID: <3802EF30.B10F2D46@lemburg.com>

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.

> As for thread-safety, this would require more complete understanding, and
> having never used mxODBC, I can't speak to its safety (which is also
> dependent on the drivers).
> 
> Note that mxODBC has an incompatible license to ours.

True. mxODBC is not 100% true Open Source even though you do get
to see the source code. In fact the license is going to be changed
to a classical "pay for commercial, free for non-commercial use"
one in one of the next versions to help finance further development
(I'm planning to take the PythonWare approach here: cheap but not
free). The main focus will then be to make mxODBC faster, more
flexible and to provide some useful add-ons.

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.

IBM DB2 is on the wish list. It should work just fine once I get
the linkage problems settled.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                    80 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/



From petrilli@digicool.com  Tue Oct 12 14:45:40 1999
From: petrilli@digicool.com (Christopher Petrilli)
Date: Tue, 12 Oct 1999 09:45:40 -0400
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
Message-ID: <199910121345.JAA03735@python.org>

> 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.
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.

> 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.  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.

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


From adustman@comstar.net  Tue Oct 12 16:17:20 1999
From: adustman@comstar.net (Andy Dustman)
Date: Tue, 12 Oct 1999 11:17:20 -0400 (EDT)
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
In-Reply-To: <199910121345.JAA03735@python.org>
Message-ID: 

On Tue, 12 Oct 1999, Christopher Petrilli wrote:

> 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.
> 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.

I guess I did "the right thing" on MySQLdb: Create a native interface
(_mysql) with a Python DB API wrapper (MySQLdb). It turned out to be very
easy to convert the old ZMySQLDA (using MySQLmodule-1.4) to use _mysql,
and MySQLmodule and _mysql are quite dissimilar.

It might be worth pointing out (not to AMK or MAL, they know this) that
Solid's native interface is ODBC.

-- 
andy dustman       |     programmer/analyst     |      comstar.net, inc.
telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d



From petrilli@digicool.com  Tue Oct 12 16:19:11 1999
From: petrilli@digicool.com (Christopher Petrilli)
Date: Tue, 12 Oct 1999 11:19:11 -0400
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
Message-ID: <199910121519.LAA07778@python.org>

> On Tue, 12 Oct 1999, Christopher Petrilli wrote:
> 
>> 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.
>> 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.
>
> I guess I did "the right thing" on MySQLdb: Create a native interface
> (_mysql) with a Python DB API wrapper (MySQLdb). It turned out to be very
> easy to convert the old ZMySQLDA (using MySQLmodule-1.4) to use _mysql,
> and MySQLmodule and _mysql are quite dissimilar.
>
> It might be worth pointing out (not to AMK or MAL, they know this) that
> Solid's native interface is ODBC.

We realize this, but SOLID has been repositioned as an embedded solution,
and since we have no customers who us it, it's been pushed out to the
general populace.

Chris

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


From mal@lemburg.com  Tue Oct 12 16:28:22 1999
From: mal@lemburg.com (M.-A. Lemburg)
Date: Tue, 12 Oct 1999 17:28:22 +0200
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
References: <199910121248.IAA11649@starship.skyport.net>
Message-ID: <38035396.ECA67777@lemburg.com>

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/



From petrilli@digicool.com  Tue Oct 12 18:48:00 1999
From: petrilli@digicool.com (Christopher Petrilli)
Date: Tue, 12 Oct 1999 13:48:00 -0400
Subject: [Zope-dev] Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC
 DA
Message-ID: <199910121748.NAA13130@python.org>

>> 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


From michel@digicool.com  Tue Oct 12 19:33:54 1999
From: michel@digicool.com (Michel Pelletier)
Date: Tue, 12 Oct 1999 14:33:54 -0400
Subject: [Zope-dev] Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC
 DA
References: <199910121748.KAA24864@zope.codeit.com>
Message-ID: <38037F12.328FA6B@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


From msrisney@ingr.com  Wed Oct 13 06:29:31 1999
From: msrisney@ingr.com (Risney, Marc S)
Date: Wed, 13 Oct 1999 00:29:31 -0500
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA : any ADO planned suppor
 t??
Message-ID: <0534AD5B0B58D21190B1080009B96E8978C8AA@HQ2>

Chris, are there plans for ADO support from Zope in the future??

Darn, As much as I want to build with Zope, I move fast and furiosly with
.ASP, 
hope that ADO is considered.....
 





From billtut@microsoft.com  Wed Oct 13 07:21:23 1999
From: billtut@microsoft.com (Bill Tutt)
Date: Tue, 12 Oct 1999 23:21:23 -0700
Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA : any ADO pl
 anned suppor t??
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB9139E@RED-MSG-50>

Do you mean on Unix, or on Win32 platforms?

Assuming you mean on Win32 platforms you can use ADO from within Python
already... See http://www.python.org/windows/win32com/ for more information
on how to go about doing that...

If you mean on Unix, I'll agree with you there.
OLE DB is a much more comprehensive/flexible API to talk to datasources with
then ODBC is. I just wish OLE DB/ADO was available on platforms besides
Win32. *sigh*

Bill

> -----Original Message-----
> From: Risney, Marc S [mailto:msrisney@ingr.com]
> Sent: Tuesday, October 12, 1999 10:30 PM
> To: 'Christopher Petrilli'
> Cc: 'db-sig@python.org'; 'mal@lemburg.com'
> Subject: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA : any ADO
> planned suppor t??
> 
> 
> Chris, are there plans for ADO support from Zope in the future??
> 
> Darn, As much as I want to build with Zope, I move fast and 
> furiosly with
> .ASP, 
> hope that ADO is considered.....
>  
> 
> 
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://www.python.org/mailman/listinfo/db-sig
> 


From m.perkonigg@carinthia-edv.co.at  Fri Oct 22 11:31:08 1999
From: m.perkonigg@carinthia-edv.co.at (Michael Perkonigg)
Date: Fri, 22 Oct 1999 11:31:08 +0100
Subject: [DB-SIG] ODBC for OS/2?
Message-ID: 


Hi!

I'm new to the SIG.
My point of interest is a portable ODBC module for Win, OS/2 and Unix, I'm
playing around with the DB/2 UDB on these systems.
I hope someone has build such a module (maybe mxODBC?).

Mike




From deirdre@deirdre.net  Fri Oct 22 18:02:24 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Fri, 22 Oct 1999 10:02:24 -0700 (PDT)
Subject: [DB-SIG] ODBC for OS/2?
In-Reply-To: 
Message-ID: 

On Fri, 22 Oct 1999, Michael Perkonigg wrote:

> I'm new to the SIG.
> My point of interest is a portable ODBC module for Win, OS/2 and Unix, I'm
> playing around with the DB/2 UDB on these systems.
> I hope someone has build such a module (maybe mxODBC?).

I have been toying around with a DB2 build but haven't gotten very far.
I've been pulled off one project at a time (my interrupts have been
interrupted). The current thing I'm doing is writing a Linux Database
Whitepaper.

My experience with ODBC on various platforms is bad enough that I'd rather
spend the extra time to implement it directly rather than via ODBC.

-- 
_Deirdre   *   http://www.linuxcabal.net   *   http://www.deirdre.net
"Mars has been a tough target" -- Peter G. Neumann, Risks Digest Moderator
"That's because the Martians keep shooting things down." -- Harlan Rosenthal
, retorting in Risks Digest 20.60