From amk@magnet.com Mon Sep 8 23:52:23 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 8 Sep 1997 18:52:23 -0400 (EDT) Subject: [DB-SIG] What DB-API compliant interfaces are there? Message-ID: <199709082252.SAA29796@lemur.magnet.com> I'd really like to write a brief article on a Python database interface for the February issue of Linux Journal. (Deadline Oct. 1.) It would be most useful, I think, if it covered the DB-API, instead of some idiosyncratic interface; that way it can end saying "this same interface works for other databases as well." But the available interfaces are for Oracle, Informix, and SOLID, which aren't common database interfaces. Are there DB-API compliant interfaces for something smaller and simpler like mSQL? SOLID's available free for Linux in a limited version, so it's not a major point. Do you think this is a good idea? Or would it be better to write about something really easy to acquire like mSQL, whether it supports the DB-API or not? Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ct7@unicornsrest.org Tue Sep 9 05:43:58 1997 From: ct7@unicornsrest.org (W. Craig Trader) Date: Tue, 09 Sep 1997 00:43:58 -0400 Subject: [DB-SIG] What DB-API compliant interfaces are there? References: <199709082252.SAA29796@lemur.magnet.com> Message-ID: <3414D40E.5363@unicornsrest.org> Andrew Kuchling wrote: > > I'd really like to write a brief article on a Python database > interface for the February issue of Linux Journal. (Deadline Oct. 1.) > It would be most useful, I think, if it covered the DB-API, instead of > some idiosyncratic interface; that way it can end saying "this same > interface works for other databases as well." But the available > interfaces are for Oracle, Informix, and SOLID, which aren't common > database interfaces. Are there DB-API compliant interfaces for > something smaller and simpler like mSQL? SOLID's available free for > Linux in a limited version, so it's not a major point. > > Do you think this is a good idea? Or would it be better to write > about something really easy to acquire like mSQL, whether it supports > the DB-API or not? Given the nature of the Linux Journal and its audience, I'd suggest targetting a database that's available for Linux. While mSQL is a popularly available database, I'd actually suggest MySQL (http://www.tcx.se/) instead. MySQL is a multi-threaded database engine with a superior SQL engine, which uses very similar APIs to mSQL, with a cheaper license. I found that it was easier to install than mSQL (there are several binary distributions available, including an RPM distribution). Drivers are available for Python, Java, and ODBC. Just my 2 cents... -- W. Craig Trader | Excellence can be attained if you: Production Manager | Care more than others think is wise Barking Mad Productions | Risk more than others think is safe mailto:ct7@unicornsrest.org | Dream more than others think is practical http://www.unicornsrest.org | Expect more than others think is possible. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pa@tekla.fi Tue Sep 9 07:29:21 1997 From: pa@tekla.fi (Harri Pasanen) Date: Tue, 9 Sep 1997 09:29:21 +0300 Subject: [DB-SIG] What DB-API compliant interfaces are there? In-Reply-To: <199709082252.SAA29796@lemur.magnet.com> References: <199709082252.SAA29796@lemur.magnet.com> Message-ID: <9709090629.AA01965@tahma.tekla.fi> Andrew Kuchling writes: > I'd really like to write a brief article on a Python database > interface for the February issue of Linux Journal. (Deadline Oct. 1.) > It would be most useful, I think, if it covered the DB-API, instead of > some idiosyncratic interface; that way it can end saying "this same > interface works for other databases as well." But the available > interfaces are for Oracle, Informix, and SOLID, which aren't common > database interfaces. Are there DB-API compliant interfaces for > something smaller and simpler like mSQL? SOLID's available free for > Linux in a limited version, so it's not a major point. > > Do you think this is a good idea? Or would it be better to write > about something really easy to acquire like mSQL, whether it supports > the DB-API or not? > My understanding is that Solid uses ODBC as its native interface even on Unix platforms, so the knowledge on that would be usable with other ODCB supporting databases as well. Solid server itself is quite small, it's the documentation and helper programs that increase the distribution size. Minimum requirements for the server are 386, 1MB RAM, 2MB disk. You can get a free Linux version for personal use. I recall about 10000 users have downloaded the free Linux version. For more information on this and Solid in general, see http://www.solidtech.com I think Linux Journal may have carried a product review of Solid in the past, so your article might complement it nicely. Harri PS. I do know a few people at Solid-Tech, and I used to work at their predecessor company, so in that sense I'm biased. > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From cjr@bound.xs4all.nl Tue Sep 9 11:48:41 1997 From: cjr@bound.xs4all.nl (Case Roole) Date: Tue, 9 Sep 1997 11:48:41 +0100 (WET DST) Subject: [DB-SIG] What DB-API compliant interfaces are there? In-Reply-To: <199709082252.SAA29796@lemur.magnet.com> from "Andrew Kuchling" at Sep 8, 97 06:52:23 pm Message-ID: <199709091048.LAA02345@axiom.bound.xs4all.nl> > > I'd really like to write a brief article on a Python database > interface for the February issue of Linux Journal. (Deadline Oct. 1.) Bravo! > It would be most useful, I think, if it covered the DB-API, instead of > some idiosyncratic interface; that way it can end saying "this same > interface works for other databases as well." But the available > interfaces are for Oracle, Informix, and SOLID, which aren't common > database interfaces. Are there DB-API compliant interfaces for > something smaller and simpler like mSQL? SOLID's available free for > Linux in a limited version, so it's not a major point. Hmm, the Python Database API mentions a pg95db module which is supposed to be compliant, but my Postgres95 module is called pg95 and a comparison of functions showed that the pg95 module is not compliant. But perhaps there is a DB API compliant wrapper around somewhere? For a project of my own it would be wonderful to have a common interface, especially to the available Linux dbms's. I don't know about the popularity of SOLID in the Linux community, but it might be a good idea to mention that there are also modules for mSQL and Postgres95 in the *first* paragraph of the article. > > Do you think this is a good idea? Or would it be better to write > about something really easy to acquire like mSQL, whether it supports > the DB-API or not? > Hmm, depends on what you like to be the spirit of the Linux community. Linux software and documentation "knows" a lot about Apple and Microsoft software where the reverse attitude is studied ignorance. This is not a matter for moral dispute, but a fact indicating where the burder lies. Similarly, python programmers will have to deal with the production of interfaces to applications and languages. These could easily be produced by the makers, but they do C, not python. Those who want to do programming in python must necessarily depend on the activities of their peers, e.g. for writing interfaces to tcl/tk, OpenGL, etc. The same goes in the Linux community. Eh, what was your question? Oh yes, if you want to promote "Linux or burst" I think you'd best stick to mSQL and/or Postgres95. On the other hand, if you want to promote python as a tool for opening up new worlds for Linux a drive to generalization of interfaces and mentioning the commercial set of DBMSs would be a good thing. Please, take this long-winded-and-not-entirely-to-the-point answer as an indication that the topic on which you plan to work can raise interest. Cheers, cjr -- Case Roole _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From hiren@lexis-nexis.com Tue Sep 9 14:34:45 1997 From: hiren@lexis-nexis.com (Hiren Hindoccha) Date: Tue, 9 Sep 1997 09:34:45 -0400 (EDT) Subject: [DB-SIG] Python ODBC module on UNIX Message-ID: I have the Python ODBC modules on Solaris working with iODBC (a freely available ODBC manager) and Visigenic's ODBC drivers for MS-SQL server. There were no code changes except for commenting out a few includes and this only seems to work when I compile the module statically with Python15a3. Making it a dynamic module seems to generate errors . Just thought I would share the info. If anyone is interested and has ODBC drivers for UNIX this module can be tested(more thoroughly) and released in the UNIX distribution too or as a module for UNIX also. Hiren -------------------------------------------------------- C:\BELFRY is where I keep my .BAT files. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Tue Sep 9 20:06:49 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 9 Sep 1997 15:06:49 -0400 (EDT) Subject: [DB-SIG] What DB-API compliant interfaces are there? In-Reply-To: <9709090629.AA01965@tahma.tekla.fi> (message from Harri Pasanen on Tue, 9 Sep 1997 09:29:21 +0300) Message-ID: <199709091906.PAA25731@lemur.magnet.com> Harri Pasanen wrote: >My understanding is that Solid uses ODBC as its native interface even >on Unix platforms, so the knowledge on that would be usable with other >ODCB supporting databases as well. Hmmm... that seems to be the case. Does that mean that you could take Michael Lausch's Solid module, and tweak it to work with another ODBC database on Linux? In other words, does ODBC specify a complete C API, or does it simply define a set of capabilities that must be supported? Case Roole wrote: >especially to the available Linux dbms's. I don't know about the popularity >of SOLID in the Linux community, but it might be a good idea to mention that >there are also modules for mSQL and Postgres95 in the *first* paragraph of >the article. Yes, that's a very good idea (assuming SOLID is covered in the article--I've just downloaded it and am figuring out how to install it.) The API spec says: >Note: The ODBC module implements a newer version of this >specification. Some additional error types were added to DBI. A spec >update is due. Shouldn't someone make this update? Since it only involves some new types, it doesn't seem like a major task... Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Tue Sep 9 21:23:07 1997 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 9 Sep 1997 13:23:07 -0700 Subject: [DB-SIG] What DB-API compliant interfaces are there? Message-ID: ODBC is a set of C APIs to access a database using SQL. I say set of APIs because ODBC has different "levels" of compliance. e.g.: The latest Microsoft ODBC SDK is at ODBC 3.0 with 3.5 in development. The organization of ODBC is something like this: ODBC Driver Manager ------------------------------------------------------------------------ ------- SQL Server ODBC Driver | SOLID ODBC Driver | etc.... The Driver Manager is what the ODBC API's call into. Now obvoiously, not all databases support the same SQL features. e.g. mSQL vs a commercial SQL database The ODBC API includes functions to help determine if your driver has a certain feature or not.. e.g. transaction capibility. So getting the SOLID ODBC code to work with say, MySQL's Unix odbc interface, or mSQL's Unix odbc interface should be trivial. Documentation is always the last thing to get updated.... :) On my free time Python TODO list: (probably in priority order) Doing a decent at least ANSI-92 capable datetime type for DBI in C to avoid the CRT 1970/y2k problem. Modifying the ODBC code to allow the parameter of an insert statement to be a sequence of rows. Modifying the ODBC code to remove the 64k restriction on raw data. Modifying DBI to return a "database tuple type" instead of a list. Where database tuple type is a type where you can do the following to access the data: row[1] = value in the 2nd column row["name"] = value in the column called "name" row.name = value in the column called "name" Unfortunately.. as I'm in the process of closing on my condo, I don't have a lot of free time right now. :( Bill Not part of Microsoft PR, yada yada > -----Original Message----- > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Tuesday, September 09, 1997 12:07 PM > To: db-sig@python.org > Subject: Re: [DB-SIG] What DB-API compliant interfaces are there? > > Harri Pasanen wrote: > >My understanding is that Solid uses ODBC as its native interface even > >on Unix platforms, so the knowledge on that would be usable with > other > >ODCB supporting databases as well. > > Hmmm... that seems to be the case. Does that mean that you > could take Michael Lausch's Solid module, and tweak it to work with > another ODBC database on Linux? In other words, does ODBC specify a > complete C API, or does it simply define a set of capabilities that > must be supported? > > Case Roole wrote: > >especially to the available Linux dbms's. I don't know about the > popularity > >of SOLID in the Linux community, but it might be a good idea to > mention that > >there are also modules for mSQL and Postgres95 in the *first* > paragraph of > >the article. > > Yes, that's a very good idea (assuming SOLID is covered in the > article--I've just downloaded it and am figuring out how to install > it.) > > The API spec says: > >Note: The ODBC module implements a newer version of this > >specification. Some additional error types were added to DBI. A spec > >update is due. > > Shouldn't someone make this update? Since it only involves > some new types, it doesn't seem like a major task... > > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Tue Sep 9 21:47:48 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 9 Sep 1997 16:47:48 -0400 (EDT) Subject: [DB-SIG] What DB-API compliant interfaces are there? In-Reply-To: (message from Bill Tutt on Tue, 9 Sep 1997 13:23:07 -0700) Message-ID: <199709092047.QAA29735@lemur.magnet.com> Bill Tutt wrote: >So getting the SOLID ODBC code to work with say, MySQL's Unix odbc >interface, or mSQL's Unix odbc interface should >be trivial. Neat! I may have to try that later... Wouldn't it then be reasonable to repackage the module as a Unix OBDC module for Solid/mSQL/MySQL/GNU SQL/whatever, and have small #ifdef's only to get the names of the header files right for the various databases? >Documentation is always the last thing to get updated.... :) True enough, but it's something of a pity. It's really cool if Python presents identical interfaces to different databases, but the capability isn't really advertised very much. (It would also help if the mSQL module, which is probably the most common, obeyed the DB-API.) Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Tue Sep 9 23:19:47 1997 From: billtut@microsoft.com (Bill Tutt) Date: Tue, 9 Sep 1997 15:19:47 -0700 Subject: [DB-SIG] What DB-API compliant interfaces are there? Message-ID: It certainly sounds reasonable to me... Oh btw, the current list of exceptions for the PythonWin DBI code is: noError, opError, progError, integrityError, dataError, internalError noError is generally ment to be thrown when you have a warning i.e. Data truncated that you should know about. opError is an operational error i.e. being disconnected, data source name not found, etc.... progError is a programming error i.e. table already exists, table not found, etc... integrityError is an integirity error in the database's relational integerity i.e. a foreign key check fails dataError is a data error, i.e. Numeric value out of range, division by zero, etc... internalError is an interntal Database error, i.e. Invalid cursor state, invalid transaction state, etc... Bill > -----Original Message----- > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Tuesday, September 09, 1997 1:48 PM > To: db-sig@python.org > Subject: Re: [DB-SIG] What DB-API compliant interfaces are there? > > Bill Tutt wrote: > >So getting the SOLID ODBC code to work with say, MySQL's Unix odbc > >interface, or mSQL's Unix odbc interface should > >be trivial. > > Neat! I may have to try that later... Wouldn't it then be > reasonable to repackage the module as a Unix OBDC module for > Solid/mSQL/MySQL/GNU SQL/whatever, and have small #ifdef's only to get > the names of the header files right for the various databases? > > >Documentation is always the last thing to get updated.... :) > > True enough, but it's something of a pity. It's really cool > if Python presents identical interfaces to different databases, but > the capability isn't really advertised very much. (It would also help > if the mSQL module, which is probably the most common, obeyed the > DB-API.) > > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Wed Sep 17 15:43:43 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 17 Sep 1997 10:43:43 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? Message-ID: <199709171443.KAA19279@lemur.magnet.com> In the DB-API, Connection objects have commit() and rollback() methods to commit or abort a transaction. However, the API doesn't specify how to indicate the *start* of a transaction; is it database-specific? It seems like an omission from the spec; what am I missing? Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Thomas.Milliman@unh.edu (Thomas E. Milliman) Wed Sep 17 15:45:01 1997 From: Thomas.Milliman@unh.edu (Thomas E. Milliman) (Thomas E. Milliman) Date: Wed, 17 Sep 1997 10:45:01 -0400 (EDT) Subject: [DB-SIG] oracledb question Message-ID: <9709171445.AA03784@comptel.sr.unh.edu> Hi, I'm a newcomer to python and have just succeeded in writing my first script using the oracledb extensions. I was a little bit surprised at the lack of samples in the distribution and by the fact that the documentation was rather old. Is there any development still going on with this stuff? I managed to get some test scripts going by looking at mailing-list archives and would like to contribute these (very simple) samples but am not sure where to send them. I'm would also guess that a "real" python user could clean them up considerably. I'm including them in this message and hope they might be useful for other newbies like me. Tom --------------------------begin sample1.py------------------------------- #!/usr/local/bin/python # # test of connecting to oracle database # # load oracledb module # import oracledb # # create open database connection # NOTE: change "dbinstance" to database instance name # dbc=oracledb.oracledb("scott/tiger@dbinstance") # # create cursor object # cursor=dbc.cursor() # # operate on cursor with "execute" method # cursor.execute("select ename,empno from emp") # # fetch and print results # for row in cursor.fetchall(): # (name,empno) = row # # print results # print name, empno # # # close cursor # cursor.close() # # all done # ----------------------------end sample1.py------------------------------- --------------------------begin sample2.py------------------------------- #!/usr/local/bin/python # # test of connecting to oracle database # # load sys module for getting command line args # import sys # # get employee name as argument # ename=sys.argv[1] # # place ename in tuple # name=(ename,) # # load oracledb module # import oracledb # # create open database connection # NOTE: change "dbinstance" to database instance name # dbc=oracledb.oracledb("scott/tiger@dbinstance") # # create cursor object # cursor=dbc.cursor() # # select statement # select="select * from emp where ename = :1" # # operate on cursor with "execute" method to preform substitutions # cursor.execute(select,name) # # fetch results # row=cursor.fetchone() # (empno,ename,job,mgr,hiredate,sal,comm,deptno) = row # # print results # print ename, empno, job, mgr, sal, comm, deptno # # # close cursor # cursor.close() # # all done # ----------------------------end sample2.py------------------------------- +---------------------------------------------------------------------+ | Thomas E. Milliman e-mail: Thomas.Milliman@unh.edu | | Space Science Center Voice: (603) 862-2867 | | University of New Hampshire Fax: (603) 862-4685 | | Morse Hall, Rm 309 | | Durham, NH 03824-3525 | +---------------------------------------------------------------------+ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From magnus.lycka@tripnet.se Wed Sep 17 17:41:21 1997 From: magnus.lycka@tripnet.se (Magnus Lycka) Date: Wed, 17 Sep 1997 18:41:21 +0200 Subject: [DB-SIG] oracledb question + Oracle+Python+W95? In-Reply-To: <9709171445.AA03784@comptel.sr.unh.edu> Message-ID: <3.0.1.32.19970917184121.008319d0@mail1.tripnet.se> Is anyone using the Oracle interface for Python under Windows 95? (Don't laugh, this is what I have to work with!) Are there compiled files available somewhere? If not oracle, ODBC? At 10:45 1997-09-17 -0400, Thomas E. Milliman wrote: >I'm a newcomer to python and have just succeeded in writing my first >script using the oracledb extensions. I was a little bit surprised at >the lack of samples in the distribution and by the fact that the >documentation was rather old. Is there any development still going on >with this stuff? Which oracledb was that? The files that the DB-SIG point out ftp.digicool.com/pub/releases/unsupported/oracle/oracledb-0.1.3.tar.gz seems fairly recent, but on the other hand seems to have NO documentation beyond a tiny README. >I managed to get some test scripts going by looking at mailing-list >archives and would like to contribute these (very simple) samples but >am not sure where to send them. I'm would also guess that a "real" >python user could clean them up considerably. I'm including them in >this message and hope they might be useful for other newbies like me. Being a newbie in this I did appreciate them, but with all respect, almost all the comments where completely redundant. Python, being as concise and clear as it is certainly don't need this kind of comments. Comments are not decorative. If they don't make it easier to understand the code they should be removed! ># close cursor ># >cursor.close() I removed all the comment lines, and I think readability increased a lot. One important thing that makes Python readable is that the code gets very compact without getting confusing. The only ones I could imagine keeping in your examples was the initial descriptive one (which could have been a bit more precise) and the note about changing instance name. Magnus -- Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden +46(0)90 198 498, magnus.lycka@tripnet.se, www1.tripnet.se/~mly _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ct7@unicornsrest.org Wed Sep 17 18:05:50 1997 From: ct7@unicornsrest.org (W. Craig Trader) Date: Wed, 17 Sep 1997 13:05:50 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? In-Reply-To: <199709171443.KAA19279@lemur.magnet.com> Message-ID: On Wed, 17 Sep 1997, Andrew Kuchling wrote: > In the DB-API, Connection objects have commit() and rollback() methods > to commit or abort a transaction. However, the API doesn't specify > how to indicate the *start* of a transaction; is it database-specific? > It seems like an omission from the spec; what am I missing? For a typical database, when you open a connection, you've started a transaction; when the connection is closed the database will either commit or rollback (it depends upon the database) the transaction. If you choose to commit or rollback the transaction on a connection yourself, that transaction will be stopped and a new transaction will be started. You *will* need to check with your database vendor's documentation about whether the default is to commit or to rollback the transaction. Illustra commits by default; MySQL and mSQL don't support transactions at all. Those are the only databases I've used that have Python interfaces (and none of those interfaces use the DB-API). -- W. Craig Trader | Excellence can be attained if you: Production Manager | Care more than others think is wise Barking Mad Productions | Risk more than others think is safe mailto:ct7@unicornsrest.org | Dream more than others think is practical http://www.unicornsrest.org | Expect more than others think is possible. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Wed Sep 17 17:03:30 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Wed, 17 Sep 1997 09:03:30 -0700 Subject: [DB-SIG] Transactions: how to start them? Message-ID: <0845FCDE78BFD011A17600805FD43A8F0108F468@RED-45-MSG.dns.microsoft.com> You always have a transaction running -- when you open a connection, that starts the transaction. When you close one (by commit or rollback), the next is automatically started. M. > -----Original Message----- > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Wednesday, September 17, 1997 7:44 AM > To: db-sig@python.org > Subject: [DB-SIG] Transactions: how to start them? > > In the DB-API, Connection objects have commit() and rollback() methods > to commit or abort a transaction. However, the API doesn't specify > how to indicate the *start* of a transaction; is it database-specific? > It seems like an omission from the spec; what am I missing? > > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Wed Sep 17 18:34:27 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 17 Sep 1997 13:34:27 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? In-Reply-To: (ct7@unicornsrest.org) Message-ID: <199709171734.NAA03789@lemur.magnet.com> "W. Craig Trader" wrote: >For a typical database, when you open a connection, you've started a >transaction; when the connection is closed the database will either commit >or rollback (it depends upon the database) the transaction. If you choose OK; thanks! I think it would be a good idea to make this explicit in the DB-API specification. >Illustra commits by default; MySQL and mSQL don't support transactions at >all. Those are the only databases I've used that have Python interfaces >(and none of those interfaces use the DB-API). Since it was decided to keep the DB-SIG alive under Michael McLay's ownership, what's the SIG's mission now? At the time of the switch, Michael wrote: >I'd like to keep it alive, so I'll take over as the sig champion. I >think it needs to stay open until a few more databases are compliant >with the db interface standard. (In particuular the mSQL interface I'm working on an LJ article about the API; if it gets finished in time and accepted, it'll appear in February. That would give us some time to improve the text of the DB-API spec, and possibly to make the mSQL, mySQL, and/or Postgres95 interfaces compliant with it. The list of supported databases needs to be more impressive. :) Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Wed Sep 17 19:45:00 1997 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 17 Sep 1997 11:45:00 -0700 Subject: [DB-SIG] Transactions: how to start them? Message-ID: Erm.. just to be annoying.. ODBC drivers default to autocommiting every SQL statement that's executed. You have to explicitly tell the ODBC driver to turn autocommiting off. Currently (as an obnoxious hack) the PythonWin ODBC interface has a setautocommit() method that you can call to turn off autocommiting after every cursor.execute(). Does this sound like a useful feature or should the ODBC module be tweaked to automatically turn off the ODBC driver's autocommit feature? Bill > -----Original Message----- > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Wednesday, September 17, 1997 10:34 AM > To: db-sig@python.org > Subject: Re: [DB-SIG] Transactions: how to start them? > > "W. Craig Trader" wrote: > >For a typical database, when you open a connection, you've started a > >transaction; when the connection is closed the database will either > commit > >or rollback (it depends upon the database) the transaction. If you > choose > > OK; thanks! I think it would be a good idea to make this > explicit in the DB-API specification. > > >Illustra commits by default; MySQL and mSQL don't support > transactions at > >all. Those are the only databases I've used that have Python > interfaces > >(and none of those interfaces use the DB-API). > > Since it was decided to keep the DB-SIG alive under Michael > McLay's ownership, what's the SIG's mission now? At the time of the > switch, Michael wrote: > > >I'd like to keep it alive, so I'll take over as the sig champion. I > >think it needs to stay open until a few more databases are compliant > >with the db interface standard. (In particuular the mSQL interface > > I'm working on an LJ article about the API; if it gets > finished in time and accepted, it'll appear in February. That would > give us some time to improve the text of the DB-API spec, and possibly > to make the mSQL, mySQL, and/or Postgres95 interfaces compliant with > it. The list of supported databases needs to be more impressive. :) > > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Wed Sep 17 19:46:02 1997 From: billtut@microsoft.com (Bill Tutt) Date: Wed, 17 Sep 1997 11:46:02 -0700 Subject: [DB-SIG] oracledb question + Oracle+Python+W95? Message-ID: For Win32 systems you'll be much better off just using the ODBC module that comes with PythonWin. Bill > -----Original Message----- > From: Magnus Lycka [SMTP:magnus.lycka@tripnet.se] > Sent: Wednesday, September 17, 1997 9:41 AM > To: Thomas.Milliman@unh.edu; db-sig@python.org > Subject: Re: [DB-SIG] oracledb question + Oracle+Python+W95? > > Is anyone using the Oracle interface for Python under Windows 95? > (Don't laugh, this is what I have to work with!) Are there compiled > files available somewhere? If not oracle, ODBC? > > At 10:45 1997-09-17 -0400, Thomas E. Milliman wrote: > >I'm a newcomer to python and have just succeeded in writing my first > >script using the oracledb extensions. I was a little bit surprised > at > >the lack of samples in the distribution and by the fact that the > >documentation was rather old. Is there any development still going > on > >with this stuff? > > Which oracledb was that? The files that the DB-SIG point out > > ftp.digicool.com/pub/releases/unsupported/oracle/oracledb-0.1.3.tar.gz > > seems fairly recent, but on the other hand seems to have NO > documentation beyond a tiny README. > > >I managed to get some test scripts going by looking at mailing-list > >archives and would like to contribute these (very simple) samples but > >am not sure where to send them. I'm would also guess that a "real" > >python user could clean them up considerably. I'm including them in > >this message and hope they might be useful for other newbies like me. > > Being a newbie in this I did appreciate them, but with all respect, > almost all the comments where completely redundant. Python, being as > concise and clear as it is certainly don't need this kind of > comments. Comments are not decorative. If they don't make it easier > to understand the code they should be removed! > > ># close cursor > ># > >cursor.close() > > I removed all the comment lines, and I think readability increased > a lot. One important thing that makes Python readable is that the > code gets very compact without getting confusing. The only ones I > could imagine keeping in your examples was the initial descriptive > one (which could have been a bit more precise) and the note about > changing instance name. > > > Magnus > > -- > Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden > +46(0)90 198 498, magnus.lycka@tripnet.se, www1.tripnet.se/~mly > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Wed Sep 17 20:22:24 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 17 Sep 1997 15:22:24 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? In-Reply-To: (message from Bill Tutt on Wed, 17 Sep 1997 11:45:00 -0700) Message-ID: <199709171922.PAA07263@lemur.magnet.com> Bill Tutt wrote: >Does this sound like a useful feature or should the ODBC module be >tweaked to automatically turn off the ODBC driver's autocommit feature? Perhaps; it doesn't seem too difficult to make existing drivers automatically do a commit() after each operation, and people might expect or want to commit after every change. Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Thu Sep 18 01:47:37 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 17 Sep 1997 20:47:37 -0400 (EDT) Subject: [DB-SIG] Re: oracledb usage In-Reply-To: Message-ID: <199709180047.UAA15573@lemur.magnet.com> roy@mchip00.med.nyu.edu (Roy Smith) wrote: >I think what you want is: > > cursor.execute ('select id from annot where work = :1 and id != :2', > [work_id, annot_id]) > >Based on my initial confusion about this, and the frequency with which I >see this question come up, I think this is probably one of the weak spots >in the db package documentation. Indeed; there are only two paragraphs in the DB-API specification about it, and no examples at all, so it's easy to miss them. Consider this another potential task for the DB-SIG. Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Thu Sep 18 09:48:33 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 18 Sep 1997 01:48:33 -0700 Subject: [DB-SIG] Transactions: how to start them? Message-ID: <41135C785691CF11B73B00805FD4D2D7039869BD@RED-17-MSG.dns.microsoft.com> Actually, as I seem to recall, the execute didn't actually do the commit... it was when the cursor was closed. Seems like I ran into a problem where a cursor object was left around causing an INSERT to not be committed, thereby causing all kinds of pain. It was solved by simply deleting the reference to the cursor, but it may be a gotcha to watch out for. -g -----Original Message----- From: Bill Tutt Sent: Wednesday, September 17, 1997 11:45 AM To: 'Andrew Kuchling'; db-sig@python.org Subject: RE: [DB-SIG] Transactions: how to start them? Erm.. just to be annoying.. ODBC drivers default to autocommiting every SQL statement that's executed. You have to explicitly tell the ODBC driver to turn autocommiting off. Currently (as an obnoxious hack) the PythonWin ODBC interface has a setautocommit() method that you can call to turn off autocommiting after every cursor.execute(). Does this sound like a useful feature or should the ODBC module be tweaked to automatically turn off the ODBC driver's autocommit feature? Bill > -----Original Message----- > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Wednesday, September 17, 1997 10:34 AM > To: db-sig@python.org > Subject: Re: [DB-SIG] Transactions: how to start them? > > "W. Craig Trader" wrote: > >For a typical database, when you open a connection, you've started a > >transaction; when the connection is closed the database will either > commit > >or rollback (it depends upon the database) the transaction. If you > choose > > OK; thanks! I think it would be a good idea to make this > explicit in the DB-API specification. > > >Illustra commits by default; MySQL and mSQL don't support > transactions at > >all. Those are the only databases I've used that have Python > interfaces > >(and none of those interfaces use the DB-API). > > Since it was decided to keep the DB-SIG alive under Michael > McLay's ownership, what's the SIG's mission now? At the time of the > switch, Michael wrote: > > >I'd like to keep it alive, so I'll take over as the sig champion. I > >think it needs to stay open until a few more databases are compliant > >with the db interface standard. (In particuular the mSQL interface > > I'm working on an LJ article about the API; if it gets > finished in time and accepted, it'll appear in February. That would > give us some time to improve the text of the DB-API spec, and possibly > to make the mSQL, mySQL, and/or Postgres95 interfaces compliant with > it. The list of supported databases needs to be more impressive. :) > > > Andrew Kuchling > amk@magnet.com > http://starship.skyport.net/crew/amk/ > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@microsoft.com Thu Sep 18 10:05:31 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 18 Sep 1997 02:05:31 -0700 Subject: [DB-SIG] What DB-API compliant interfaces are there? Message-ID: <41135C785691CF11B73B00805FD4D2D7039869BE@RED-17-MSG.dns.microsoft.com> > From: Andrew Kuchling [SMTP:amk@magnet.com] > Sent: Tuesday, September 09, 1997 1:48 PM > To: db-sig@python.org > Subject: Re: [DB-SIG] What DB-API compliant interfaces are there? > > ... > True enough, but it's something of a pity. It's really cool > if Python presents identical interfaces to different databases, but > the capability isn't really advertised very much. (It would also help > if the mSQL module, which is probably the most common, obeyed the > DB-API.) Please be wary here. The (initial) intent of the API was to expose database functionality in a similar (but not exact) way across multiple databases.The interface was meant to degrade if certain functionality was not present in a particular database (e.g. as I recall mSQL doesn't have data binding nor cursors). The API was meant to follow the standard Python philosophy of "simply expose the functionality, then deal with high-level abstractions in Python". Hopefully, by minimizing abstractions within the API itself, DBAPI implementors would not have as much work. If somebody truly needs database independence, then Python-level abstractions can be built. Note: the above philosophy is why the fetch methods return lists of tuples rather than, say, a more powerful datatype that provides attribute-based access to column values (where attribute names match column names). Search the SIG archives for "DatabaseTuple" for a way to do that. At a minimum, providing a "similar-as-possible" API across databases means that learning time and coding time is greatly reduced, and therefore beneficial. Trying to make them equal is a wicked slippery slope. I gave up on an mSQL interface when I first tried a year and a half ago, but as I recall it was because mSQL didn't have binary columns (since it doesn't have data binding and binary is hard to represent in a textual SQL statement). It should be possible to actually do most of an mSQL interface. -g _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Thu Sep 18 11:38:00 1997 From: aaron_watters@classic.msn.com (aaron watters) Date: Thu, 18 Sep 97 10:38:00 UT Subject: [DB-SIG] Transactions: how to start them? Message-ID: Just to be more annoying, I think I agree with Mark H. that ODBC should be exposed moreorless directly to Python and the DB-API stuff should be a wrapper layer for it. BTW: What is the status of the sybase module, anybody? I'll look into it soon, since I have a possible client interest and I'm teaching a db class at rutgers where they have sybase... -- Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Bill Tutt Sent: Wednesday, September 17, 1997 2:45 PM To: 'Andrew Kuchling'; db-sig@python.org Subject: RE: [DB-SIG] Transactions: how to start them? Erm.. just to be annoying.. ODBC drivers default to autocommiting every SQL statement that's executed. You have to explicitly tell the ODBC driver to turn autocommiting off. ... _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From shprentz@bdm.com Thu Sep 18 14:20:25 1997 From: shprentz@bdm.com (Joel Shprentz) Date: Thu, 18 Sep 1997 09:20:25 -0400 Subject: [DB-SIG] Transactions: how to start them? Message-ID: <3.0.32.19970918092021.0080be20@blat.com> At 10:38 AM 9/18/97 UT, Aaron Watters wrote: >BTW: What is the status of the sybase module, anybody? >I'll look into it soon, since I have a possible client interest >and I'm teaching a db class at rutgers where they have >sybase... -- Aaron Watters I have substantially rewritten the Sybase module to support my work with persistent storage (plug: paper to be presented at Python Conference). Building on the work of other contributors, I've made these changes: - Access to Sybase's error reporting - Support for long text and image fields - More (but not all) data types supported - Access to some Sybase internals - Python function calls use new names I'll confess that my primary use of the module is to submit fairly simple SQL statements and get the results. I've not worked with calculated fields, which require different Sybase API calls to retrieve. Nor do I use stored procedures very much. I'll make the code available sometime next week when I return from some travel. -- Joel Shprentz (202) 863-3487 BDM Federal, Inc. shprentz@bdm.com 1501 BDM Way McLean, VA 22102 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From magnus.lycka@tripnet.se Thu Sep 18 16:14:56 1997 From: magnus.lycka@tripnet.se (Magnus Lycka) Date: Thu, 18 Sep 1997 17:14:56 +0200 Subject: [DB-SIG] autocommit In-Reply-To: Message-ID: <3.0.1.32.19970918171456.007b0bd0@mail1.tripnet.se> At 11:45 1997-09-17 -0700, Bill Tutt wrote: >Erm.. just to be annoying.. ODBC drivers default to autocommiting every >SQL statement that's executed. >You have to explicitly tell the ODBC driver to turn autocommiting off. > >Currently (as an obnoxious hack) the PythonWin ODBC interface has a >setautocommit() method that you can call to turn off autocommiting after >every cursor.execute(). > >Does this sound like a useful feature or should the ODBC module be >tweaked to automatically turn off the ODBC driver's autocommit feature? Most databases have the possibility to set autocommit on or off. Is this not generally available in the Python DB-API? I think it should be. Are there supported databases (which support transactions) that can't set autocommit on/off? In that case we might think of putting that in the API. That should be simple. Frankly, I haven't seen many applications that handled transactions properly. Most either use autocommit all the time even if it might cause inconsistencies if a transaction is interrupted due to an error, and some programmers who use SQL seems to be completely unaware of transactions in general, and get very confused when it turns out that their changes in the database are hidden to others until their session ends... Since the database must be able to rollback the whole transaction, you will induce performance penalties if you don't commit as often as you could. The best way to make life simple for amateurish programmers is certainly to default autocommit on. I imagine that's why ODBC works like that. I think it might be good programming practice to explicitly set autocommit on or off as desired for each new session. Whether the API should implicitly set it on... I don't know... perhaps. It would make sloppy code more portable. I think the most practical way to use SQL databases is to turn autocommit on by default, and to just turn it off where you have several SQL commands that form a common transaction. Of course, if you work very much with saving master-detail data etc you will have multi command transactions every time that you save, and it might be less job to do all your commits explicitly. To be honest, I'm a little uncertain about how to handle SQL the best way. The thing that makes it tricky is that the database has it's own states and namespaces which completely ignore your Python (or whatever) code structures / namespaces. If you don't use cursors this might make things very confusing if you call other functions containing SQL while in a transaction... Commit/rollbacks might suddenly appear in wrong places. I guess the solution to this is to always use cursors if the database supports that. -- Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden +46(0)90 198 498, magnus.lycka@tripnet.se, www1.tripnet.se/~mly _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Thu Sep 18 12:24:46 1997 From: andrich@fga.de (Oliver Andrich) Date: 18 Sep 1997 13:24:46 +0200 Subject: [DB-SIG] MySQL and similar databases Message-ID: Hi, I don't want to be a heretic, but is the Database API (current version 1.0) a must, if I want to implement a interface to MySQL, that offers some more features then the one already available? I ask, cause the API might be ok for Oracle, Informix, and so on. But I is to much for MySQL, MSQL and so on, isn't it? But may be I don't see everything that is needed to understand the API. This will be my first time at interfacing Python with DB myself and also my first bigger DB project. Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Fri Sep 19 00:07:57 1997 From: aaron_watters@classic.msn.com (aaron watters) Date: Thu, 18 Sep 97 23:07:57 UT Subject: [DB-SIG] autocommit Message-ID: Hey, the database theorists have the same problem. This is the embedded transaction problem - no one knows how to deal with it (although I wouldn't be surprised if the higher class rdbms's have some ad-hoc hacks for it that work "most of the time"). Actually few db theorist think too hard about stuff this practical, but if you asked them they wouldn't know (but they might hand wave you away)... - Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Magnus Lycka Sent: Thursday, September 18, 1997 11:15 AM To: db-sig@python.org Subject: [DB-SIG] autocommit ... To be honest, I'm a little uncertain about how to handle SQL the best way. The thing that makes it tricky is that the database has it's own states and namespaces which completely ignore your Python (or whatever) code structures / namespaces. If you don't use cursors this might make things very confusing if you call other functions containing SQL while in a transaction... Commit/rollbacks might suddenly appear in wrong places. I guess the solution to this is to always use cursors if the database supports that. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Fri Sep 19 00:09:49 1997 From: aaron_watters@classic.msn.com (aaron watters) Date: Thu, 18 Sep 97 23:09:49 UT Subject: [DB-SIG] MySQL and similar databases Message-ID: No. Do what you like, but it's nice if you implement the dbapi functionality that makes sense (either in C or as a Python wrapper layer). - Aaron Watters ps: and tell us about it when it's ready to try out! ---------- From: owner-db-sig@python.org on behalf of Oliver Andrich Sent: Thursday, September 18, 1997 7:25 AM To: db-sig@python.org Subject: [DB-SIG] MySQL and similar databases Hi, I don't want to be a heretic, but is the Database API (current version 1.0) a must, if I want to implement a interface to MySQL, that offers some more features then the one already available? I ask, cause the API might be ok for Oracle, Informix, and so on. But I is to much for MySQL, MSQL and so on, isn't it? But may be I don't see everything that is needed to understand the API. This will be my first time at interfacing Python with DB myself and also my first bigger DB project. Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Fri Sep 19 14:05:09 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Fri, 19 Sep 1997 09:05:09 -0400 Subject: [DB-SIG] autocommit References: <3.0.1.32.19970918171456.007b0bd0@mail1.tripnet.se> Message-ID: <34227885.1B9B@digicool.com> Magnus Lycka wrote: > To be honest, I'm a little uncertain about how to handle SQL the best way. > The thing that makes it tricky is that the database has it's own states > and namespaces which completely ignore your Python (or whatever) code > structures / namespaces. If you don't use cursors this might make things > very confusing if you call other functions containing SQL while in a > transaction... Commit/rollbacks might suddenly appear in wrong places. > I guess the solution to this is to always use cursors if the database > supports that. This is one of the reasons that I find object-oriented databases to be *far* more useful than relational databases. For example, an object oriented database underlies our apps, programmers have almost no database-related logic in their apps. Programers should not have to think about loading or storing data. To me, the eplicit query and update required by relational databases is roughly akin to the explicit malloc and free required by C. Jim _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim.fulton@digicool.com Fri Sep 19 14:09:14 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Fri, 19 Sep 1997 09:09:14 -0400 Subject: [DB-SIG] autocommit References: Message-ID: <3422797A.7CBB@digicool.com> aaron watters wrote: > > Hey, the database theorists have the same problem. > This is the embedded transaction problem - no one knows > how to deal with it (although I wouldn't be surprised if > the higher class rdbms's have some ad-hoc hacks for > it that work "most of the time"). We deal with it. Our database supports nested (embedded) transactions. Unfortunately, our database is not a product :( yet :). I know a number of research OO database systems support nested transactions. I'd guess that several of the commercial OODBMSs support nested transactions. For that matter, TP standards, including the CORBA transaction service support nested transactions. Jim _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Fri Sep 19 18:56:42 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Fri, 19 Sep 1997 10:56:42 -0700 Subject: [DB-SIG] MySQL and similar databases Message-ID: <0845FCDE78BFD011A17600805FD43A8F0108F476@RED-45-MSG.dns.microsoft.com> It was intended as a minimum set of functionality for a relational database. What variation did you have in mind? M. > -----Original Message----- > From: Oliver Andrich [SMTP:andrich@fga.de] > Sent: Thursday, September 18, 1997 4:25 AM > To: db-sig@python.org > Subject: [DB-SIG] MySQL and similar databases > > Hi, > > I don't want to be a heretic, but is the Database API (current version > 1.0) a > must, if I want to implement a interface to MySQL, that offers some > more > features then the one already available? I ask, cause the API might be > ok for > Oracle, Informix, and so on. But I is to much for MySQL, MSQL and so > on, isn't > it? But may be I don't see everything that is needed to understand the > API. This will be my first time at interfacing Python with DB myself > and also > my first bigger DB project. > > Best regards, > > Oliver Andrich > > -- > --------------------------------------------------------------------- > FGA Furch & Graf intermediaservices gbr andrich@fga.de > Gartenstr. 5 http://www.fga.de > D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) > --------------------------------------------------------------------- > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From magnus.lycka@tripnet.se Sat Sep 20 01:45:52 1997 From: magnus.lycka@tripnet.se (Magnus Lycka) Date: Sat, 20 Sep 1997 02:45:52 +0200 Subject: [DB-SIG] autocommit In-Reply-To: <34227885.1B9B@digicool.com> References: <3.0.1.32.19970918171456.007b0bd0@mail1.tripnet.se> Message-ID: <3.0.1.32.19970920024552.00831140@mail1.tripnet.se> At 09:05 1997-09-19 -0400, Jim Fulton wrote concerning the complications of the double scope of the program and the SQL database: >This is one of the reasons that I find object-oriented databases to be >*far* more useful than relational databases. For example, an object >oriented database underlies our apps, programmers have almost no >database-related logic in their apps. Programers should not have to >think about loading or storing data. To me, the eplicit query and >update required by relational databases is roughly akin to the >explicit malloc and free required by C. Interesting. Maybe I'm deviating a bit from the purpose of the SIG now, but I think this is interesting. With centralized applications run through terminals it didn't matter so much if the rules where in the application or in the database, but with client server systems and direct database connectivity from excel or whatever, a lot of functionality except storage such as security and consistency control had to be placed on the database. This is a pain since SQL itself isn't enough and extensions such as database procedures differ between databases and lead to a strange division of where logic is placed and largely duplication of functionality. When we now are going back to centralizing business logic through three tier solutions and www systems, we can somehow lift out some of the requirements from the database again. An SQL database and an OO language in combination means that we have two incompatible and overlapping descriptions of the same thing. Sigh. Obviously the OO (eg Python) description is much more versitile, since it contains methods as well as data structures. On the other hand, SQL has it's merits, for instance in the ability to perform ad hoc searches in the data. You don't have to specify how things relate to each other until you perform the search. Does the OO alternatives provide these possibilities as well? I've never used a proper OODBMS, but I got the feeling that the relations between tables are fairly solid, like in the program code, and that it might be difficult to for instance extract all sorts of statistics that we didn't intend to provide when the system was originally designed. If this flexibility is not at all needed, I guess little more than flattening the objects is needed (ok, a slight simplification ;-) but I would like to have the flexibility for searches etc I have today with Oracle etc. It's my experience that delivered and running database systems always change during time: Fields change, come and go. The field which was previously free text is now validated agains another table and for another field it's the other way around. The users come up with new ideas all the time regarding what kind of statistics they want to be able to extract etc. These changes have to be made in a running environment with a few GB of data used all the time by hundreds of people. If the structure of the database was much more rigid or complex than SQL, this wouldn't work. One argument against OODBMS's I've heard is just that it's tricky to use data in a different way that initially intended. If that is a real restriction OODBMS's are in my opinion worthless in most real life apps. (It also seems like RDBMS's still are very much dominating.) On the other hand, changing an SQL database might well cause pains since the SQL code relating to one table might have to be updated due to a tiny change, and it might be spread out through the application. With an OODBMS where all operations in a class/table/relation went through class methods, this program change might be much more localized. It would be interesting to hear what you think about these issues. Magnus -- Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden +46(0)90 198 498, magnus.lycka@tripnet.se, www1.tripnet.se/~mly _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Fri Sep 19 13:39:33 1997 From: andrich@fga.de (Oliver Andrich) Date: 19 Sep 1997 14:39:33 +0200 Subject: [DB-SIG] Question concerning the DB-API Message-ID: Hi, how do I have to understand the DBAPI? Is it the minimum that a module conforming this API should provide or describes it the exact interface to the database? I ask cause I like to add some nice little methods to the module, that aren't described in the DBAPI. Or something like select_db, create_db, drob_db, .... not worth implementation? Do I have to understand the connection object as a connection to a database or as a connection to the database server? Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Fri Sep 19 10:38:49 1997 From: andrich@fga.de (Oliver Andrich) Date: 19 Sep 1997 11:38:49 +0200 Subject: [DB-SIG] MySQL and similar databases In-Reply-To: "aaron watters"'s message of Thu, 18 Sep 97 23:09:49 UT References: Message-ID: "aaron watters" writes: > No. Do what you like, but it's nice if you implement > the dbapi functionality that makes sense (either in C > or as a Python wrapper layer). - Aaron Watters Well, after looking a little bit at the MySQL API and thinking about our API, I think that I it would be better to implement a MySQL interface using our API, cause it makes sense after some thinking. > ps: and tell us about it when it's ready to try out! Of course. Best regards, Oliver Andrich _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Fri Sep 19 19:23:43 1997 From: andrich@fga.de (Oliver Andrich) Date: 19 Sep 1997 20:23:43 +0200 Subject: [DB-SIG] Again a question concering the API from a newbie Message-ID: Hi, can anybody give me an example for execute(operation, params)? I mean something where I can learn from what this thing with the params means and if this is the case with my mySQL interface or not. Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Sat Sep 20 08:31:52 1997 From: Anthony Baxter (Anthony Baxter) Date: Sat, 20 Sep 1997 17:31:52 +1000 Subject: [DB-SIG] Again a question concering the API from a newbie In-Reply-To: Your message of "19 Sep 1997 20:23:43 +0200." Message-ID: <199709200731.RAA18814@jambu.off.connect.com.au> >>> Oliver Andrich wrote > can anybody give me an example for execute(operation, params)? I mean > something where I can learn from what this thing with the params means and if > this is the case with my mySQL interface or not. an example of this would be something like curs.execute("""INSERT INTO test_table VALUES ( :1, :2, '20-NOV-96' )""", (3,"hello")) the :1 :2 &c are placeholders in the SQL - the parameters are substituted in. You can also pass a list of tuples and have it substitute each tuple in turn. Why would you do this? It's somewhat neater than string interpolation, and it saves having to reparse the SQL each time. I don't have my Oracle docs here, so I can't tell you the fancy term they use for this - input binding, I think... Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Sun Sep 21 02:34:04 1997 From: aaron_watters@classic.msn.com (aaron watters) Date: Sun, 21 Sep 97 01:34:04 UT Subject: [DB-SIG] autocommit Message-ID: Sorry for my ignorance. What do they do? EG: Outer transaction debits my account Inner transaction uses this information to print out a receipt on my computer after commit Outer transaction decides it can't debit my account after all and backs out. How are we to unprint my receipt? I promise to look into this some more (I've not been paying attention for about 3 years). Nevertheless a simple walkthrough would be helpful. The schemes I've seen were flawed. * Aaron Watters ---------- From: Jim Fulton Sent: Friday, September 19, 1997 9:09 AM To: aaron watters Cc: db-sig@python.org; Magnus Lycka Subject: Re: [DB-SIG] autocommit aaron watters wrote: > > Hey, the database theorists have the same problem. > This is the embedded transaction problem - no one knows > how to deal with it (although I wouldn't be surprised if > the higher class rdbms's have some ad-hoc hacks for > it that work "most of the time"). We deal with it. Our database supports nested (embedded) transactions. Unfortunately, our database is not a product :( yet :). I know a number of research OO database systems support nested transactions. I'd guess that several of the commercial OODBMSs support nested transactions. For that matter, TP standards, including the CORBA transaction service support nested transactions. Jim _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Sun Sep 21 03:59:51 1997 From: Anthony Baxter (Anthony Baxter) Date: Sun, 21 Sep 1997 12:59:51 +1000 Subject: [DB-SIG] Question concerning the DB-API In-Reply-To: Your message of "19 Sep 1997 14:39:33 +0200." Message-ID: <199709210259.MAA20393@jambu.off.connect.com.au> >>> Oliver Andrich wrote > how do I have to understand the DBAPI? Is it the minimum that a module > conforming this API should provide or describes it the exact interface to the > database? I ask cause I like to add some nice little methods to the module, > that aren't described in the DBAPI. I'd suggest that they should be layered on top of a DB-API interface. The DB-API is a fairly low-level one (deliberately, I feel), so that it can be implemented on as many databases as possible. Some databases are just not going to be able to provide a full DB-API interface (mSQL for one...) so I guess they should try to provide as much as possible. > Or something like select_db, create_db, > drob_db, .... not worth implementation? select, create, drop, insert, &c could probably be put in a seperate SQL module that just accepted a cursor and made it easier to build up the SQL statement. This could then sit on top of any DB-API compliant module. > Do I have to understand the connection > object as a connection to a database or as a connection to the database > server? I consider a connection object as a connection to a database. Some of my code connects to multiple databases using different connection objects for each one. Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Thu Sep 25 00:26:53 1997 From: amk@magnet.com (Andrew Kuchling) Date: Wed, 24 Sep 1997 19:26:53 -0400 (EDT) Subject: [DB-SIG] First draft of an article Message-ID: <199709242326.TAA05351@lemur.magnet.com> I've finally managed to complete a rough first draft of an article about the API; I couldn't really get a handle on it, but maybe after some comments from the group and some editorial advice it can be improved. http://starship.skyport.net/crew/amk/writing/DB-API.html Comments are *very* welcome; contributing better prose and examples will get you a co-author credit... Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mclay@nist.gov Fri Sep 26 15:01:47 1997 From: mclay@nist.gov (Michael McLay) Date: Fri, 26 Sep 1997 10:01:47 -0400 Subject: [DB-SIG] Transactions: how to start them? Message-ID: <199709261401.KAA03052@fermi.eeel.nist.gov> Andrew Kuchling writes: > "W. Craig Trader" wrote: > >For a typical database, when you open a connection, you've started a > >transaction; when the connection is closed the database will either commit > >or rollback (it depends upon the database) the transaction. If you choose > > OK; thanks! I think it would be a good idea to make this > explicit in the DB-API specification. > > >Illustra commits by default; MySQL and mSQL don't support transactions at > >all. Those are the only databases I've used that have Python interfaces > >(and none of those interfaces use the DB-API). > > Since it was decided to keep the DB-SIG alive under Michael > McLay's ownership, what's the SIG's mission now? At the time of the > switch, Michael wrote: > > >I'd like to keep it alive, so I'll take over as the sig champion. I > >think it needs to stay open until a few more databases are compliant > >with the db interface standard. (In particuular the mSQL interface I think the discussion over the last couple weeks indicates that this SIG has more work to do. The DB-API defines a minimal general purpose API for accessing SQL, but we need to keep the SIG open as a place to discuss implementation problems and to support the development of solutions to specific problems, such as establishing a standard interface behavior for transaction processing. Perhaps a transaction API should be the next target. I think Eric Newton was doing some work on a transaction interface a year or so ago and Jim Fulton work on Bobo probably means he has will have something to say on the subject. > The list of supported databases needs to be more impressive. :) Yes, more databases would be nice. Another problem is a lack of a test database with test script to demonstrate conformance and performance of the DB-API. (It could also make a nice demonstration.) Some code that may be useful in building a test suite might be found in the SQL tests at http://www.nist.gov/itl/div897/ctg/sql_form.htm. The Conformance Testing Group (http://www.itl.nist.gov/div897/ctg/ctg.htm) developed this test suite. The group have redefined their mission recently. I found this quote in one of there documents: NIST is exploring broader based methods for accessing unstructured information, including natural language queries, and new mechanisms for object-oriented access to multimedia data. I don't know of anyone in that group who is looking at Python. I guess that means that industry hasn't ask them to research the subject. Hint, Hint, nudge, nudge, wink, wink, know what I mean? _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ecn@smart.net Fri Sep 26 15:43:20 1997 From: ecn@smart.net (Newton Consulting Inc) Date: Fri, 26 Sep 1997 10:43:20 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? In-Reply-To: <199709261401.KAA03052@fermi.eeel.nist.gov> Message-ID: > I think Eric Newton was doing some work on a transaction > interface a year or so ago I was thinking about database operations as atomic nodes in a much bigger framework for information systems. The basic idea was to view an information processing system as network of workflow nodes. The framework standardized the data types and connection interfaces between nodes, and then it allowed any old database operation to be implemented inside the node. It is a useful integration framework, and one that lends itself well to Python. I don't know how much it will help you, though. For example, it is a fine way to integrate report generators, too. Nobody pays me to build information systems these days, so my interest has waned. -Eric _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From amk@magnet.com Fri Sep 26 17:45:18 1997 From: amk@magnet.com (Andrew Kuchling) Date: Fri, 26 Sep 1997 12:45:18 -0400 (EDT) Subject: [DB-SIG] Transactions: how to start them? In-Reply-To: <199709261401.KAA03052@fermi.eeel.nist.gov> (message from Michael McLay on Fri, 26 Sep 1997 10:01:47 -0400) Message-ID: <199709261645.MAA17168@lemur.magnet.com> Michael McLay wrote: >Yes, more databases would be nice. Another problem is a lack of a >test database with test script to demonstrate conformance and >performance of the DB-API. (It could also make a nice demonstration.) Indeed. So that means the SIG still has at least 2 areas where work could be done. 1) Tidy up and clarify the text of the DB-API specification, clarifying how transactions work, and perhaps adding a simple example here and there. This would mostly be an editing job. 2) Producing more API-compliant database modules, and a testing script to verify a module's conformance with the spec, and perhaps its speed. Andrew Kuchling amk@magnet.com http://starship.skyport.net/crew/amk/ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Mon Sep 29 22:25:57 1997 From: andrich@fga.de (Oliver Andrich) Date: Mon, 29 Sep 1997 23:25:57 +0200 Subject: [DB-SIG] New mysqldb module 0.1 Message-ID: <19970929232557.47238@fga.de> --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Hi, as I promised, I like to announce the first beta release of my new, DB-SIG API conforming mysqldb module for Python. I hope that the attachment of the modules source code doesn't violate the policy for posting articles on this list. Sadly, I haven't found a home in WWW yet. ;-) The attached tar-ball includes mysqldb.c (the module) and a README file, that describes the module. Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- --h31gzZEtNLTqOjlF Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mysqldb.tgz" H4sIALQcMDQAA+1ce3fbtpLv3/oUqNr1Ur60bOe5sa5717GVRLt+re2025Pt4aFIyGLNh0pS VtQ0333nAfChJ+VXe3fF08YiCQwGMz/MDIYALtoHRyftbx712t3ZefXihfhGCPH61Sv6+3x3 h/7i9er5y1fw74vdFzu7r3ZfPRNid+f1s+ffiJ3HZYuvYZLasRDf2KEbe05/bjko1us9BUNP e12Q/kUvikUwTn7z3a7Yae7W9mdetdpV30tEEvXSkR1LAb+dKEw8V8bSFW/bVwf5OzsVaV8K ZxjHMoTfXiCb4gqfRINx7F3301oYpZ6TlezKay8MvfBaRD160PN8agJ/x9KXtzbQyWoLLwSm Azv1ohDZr2GxIHKHWClNpN8ToFKoDBR0J4FgE/uQFQTukUgC98AyyMCXCTQYUZtRr+c5nu2L 83Hah0aO3m4dnHdMMfLSPhao9SLfj0bE8QDZSMQwke5erbYlwgh7ngDFqPurdFLshxcMfBmA MEBWjg1FWeLCjWQS/msqkuFgEMWpqpiIsUybNSGMA+jGKMISXSk64noIPDYb0AhLMwyBPgpB tTRJjuQioQcuaisIvNQUMXDetZ0bFBE04di+P4gjx5zJF7y5BRWLNLbDxHa4pyjbJI1Q71hT usNYJk2xkN+uZPKkXxAItKqlpBkkVBXkZCfZK0YFcjvZZSBtx7E9Trzf5aSggYCtSCAFe4bA sCsARSoK5GNpu9uj2EsRmWnsdYcpINe4kHbCSGPmvcSEH4DdjrADqv/bEOskIAjRj0aAIuIV BGeLWzv27C4iMxSHJAtXJk7sEWyQZawP+i6yrpXRAUWgMEOgia2PuNFQQu+8VGmQHqKmfTtJ xUto0AexY3M8epKhnyJQX2+lQ2gBpWqHTeBDfpYOdHAKNQM7tgPCYM5H33axCA5lHCMZr8AG AvUnD/QJKrdvbc/XvcXmQ/k5pRFsJxLbTGRqeOEf0TBtDIYpaQ30jqSLmqOmUTcjRfdGDlI0 FiBOGY8FDD1odBB7EehqPCGsRAKKh04fRyRKicYswRoZOHoLnZH+QMYzJa9oFVU0oxQScm1E CQ6FSEApJXUEcSzTYRwyABNAUXidaFvoj7Eqgj8C6cTzaimrE4KFu5WqEFYEvLkuFgEJpNpW 8ogF8yR6w5CHKNghIaCdXg9ALt04GiVGAx5wG9DxYdCF1oEAvsrKie44B9Jl+7h9eGXWxKyr c3rZvrhCq/nx/Ojgqg39BHGgcKhhBwYS0Osabje0A9kwBfAwyO+zIiRAfIfitLsAkoQJ+B7Q QjNvQOV+lGS/weKkkb5JZAx44DuxxZrX0iA6vpekbjcxAEculMdbRGfpAdmwBFomGi47gGQg yf7/NgT6qKFktiCWXoykLg7YcII5GBaR7SrF4M9Sy1ogXIkqgGcDPZXEyI8AEOC8YVzaDnaF Id8bxoQxPcwzFbGIk/4wdaNRyJJTN8wBSVUYNNRCdNNeT4yjIcoGxlMvjgJoMJZBlErSjdjb ajBNaKIANBgaAbcLYvYcbcdVA+yNCzZZW3uwiVHojwHtYG3DG21q+/Yt2R4tURSoK1MwOLVs dAHwVShjfHK7yJsp4AcM6Zh+DOwkoR8ov1/gagCGsypcYx/GLACWKunfWE//xqr4u6FCIs22 Hlwz/EwT2Y8GUrsPIcNoeN0nmw62nYKjGplKFa6Q3fNCxx+6kgMUBDm4IqbTFK0tbh5tSxqB YozMGiov6OXjOYohSmtQcAIlwfRR9BSCYlOZABy20Kxk5h+ZQitJQ7NgBw3QAtpxFbLZiecU 65DHCwag667nAx8NRVZ5kywkiTQg4X3P+8wGB/DR86QPUuwOr/ORYmSKzcDgUTxll8uxI0RD TY/I9WL7JLmjyBki7DlcZIsNsJSfbTTo2Pvcm027JyMBQZ+DxUnRYwD3bLhdRRRM7Zbop+lg b3t7NBo1U+dzM5HbwkB9AZ9dIJUzmRsA0p4d3nA0dR1LiT4aqP1HJMXlDUTDOAJ/jeS/SxuG sY9hb9OJmuHvOLzQ6tvAEvyPBJilYHz5X8eCGO3ZjqxmrxDMLlfluLgpTsZZLJ2AK4ivK5IC XgZezKhDmI+i+Kapxy3E7ghIVlSFy3bB40MFJDQgb+j1xpmDQz0E44o9hGAJnGftz55t/fUu ZfaaziO2sXj+/3Ln+e7LbP7/7PkOzP93X73eWc//n+La3oQRdJhNyYs34t37A9H1QDzwcxhD ML0h3sd2j80LmAzPRicOsUEi3ncvTPEeSsoQvGJTvDRxKvjy1bNnO+ISXN+lBF+RejDnEAfg 1Yg+ekuKAtxmoVGaM0wkGYAUxCVsVXKmTDEMab5Opm/kYaQfup6DUWdTnAOLXpIoQwF+3KTc gbI+rpeoqd10a0BMQkPXMN2laZia/7ocg6CrAot+W0xkkNuhVMZgAKYa+0BzW7R3iUpDQNVu RIkDu5jF0BV1qgKnNDnnJbJNcRoRvzgHCsfIlzt0UlOo4BUj8VQ6/TDyo+txHnTWxLRQA3uM UyoKxIY8DYa4jH1IB7rtY0Q5xNwHxOUyhoiCVUbzY1ZaWRnUA6SMDtgHpsMELTeIchhC4NFE ZJ1G4iecqIdADu8x9CsKPhN03cYAqU4hLPrOka6FM3joObhGFycl0lPB7SBW/VdBj6niJnCn JkQJqeIq8NCdpJGpMgk6RFL0UVnQQiAB63BrcwxjQoSShkgfgyIbYxlQyhCcIupqGA8ixBYF ceEWeHyc61EggRFdUeZONPRdHdBBXdIVwBWDPIjZh7HtEAegxfEgAvgN+vRWxnEUJzBGgKlr nigySrwI0e5DYBTYrtRpK91eC+9gTDiqmppGExqcCNiOcaAgNEI5EjCaObGjw3NFpVnUMaIm sG+U6EBbPJVA3W8D27qlKbQpwGLiAHMVSqsMbkLGMaqGY7OzHtwp0RNKOjgMhLzF0Iz6UGCo i2EjpRpQNy5EHjge0ArwLzWPMrnTgC3Qqm8KCcF5FHiY74I+xKQ9TGRKmOkBDGjiFdgsay8B faIBGmaTbZXDQriFmlO2MRP9RqZh3lTDUObWwwGhKABmEhUi46MEMxWqSbCVesIE7UOoDmJC AphqpLryMwCIrAPmK3PBAZ1ZeEaUlkv5mXh71AUtlykpoJ1kpkxMcOSWr0gvLjCE+KBM2mDg jzkBBlNG0vD3x9H1nsiiDfNWfA9PLySIBWvuNt+A23/z5vX2zpvtZ2/Es929Zy/2nsND5ZfJ XPC8CfnwQo/0pLJKNGzHauJE7RUo/1uZ8s7e8xd7L54XKR9GcczJDx4yhz9eihs5huCVokax uV2r0QzWQYzHYjN2Es/dr3/fcct9wm7M6oVqSrQ/D8T39VbtO5hMW9b704+HliX298Wz2neu 7HmhFB8v28atHTeEau828lyxidiyvvsOXoh9YWxkdyZM0KlAQ2xgrRpWJ+Ya0IiEcdCrQWNq DlnnlFKzXy8846QYPMpYOLh4bx2efTy9Mv67If4nC7ANA++B2dOPx8cN8Q+xI/aEcT6+woSi ddiXzg0W+IfQjy5x5gRP9sRuo6GpZII8H5+x39lUAmyjmWvVatuboI9s7kw8eXnOWaVys9ka oxAVBEZTQmnMtoFXFF+Acd2G9QGAAfcnP+PsCKyU68sW2YQUE2ue29IvrYv2JahXJvjEj8Lr PLPcqn3Vus75Y/ot3SsYUDD2XBQBcKM6OFUJ37VyeXuJNYeucdsAsd82tn6Iuhb2D8W/MZNe IxMsAWIOQcuVaEgcQ0tmE5NHvQZJa06dTREg6Oa8BeghhRaOOQC1EWz9QBJtaIKW44ODNDbw DUu+0WiRbk5kYB21j40A7r8WcHFCKj6Svbm9UNmWT7+0puC0ObfStUwxnz+/I8GcPCdePOyx PstK5bbOx9Y78DbM8TzKml1TGDnoG4FJnxcm+r6sEyzMuV1AVVDkPefK24cpfYJdUWr79nx8 EF9b53acSBq9BhYwRb3eaKihBOPTupTpJSWzjeKghWLDBNzEnmD2GnXSsJIRmgu8/arbQia3 foAxlmOkF0tp8VeKwmuoVaoyB1j8MscWcWt1Tg8v2u9A4tZpFMoiQ+rRaoJX+aolol9F8hpU GF+zFdvPZJWXVpkz/WqZupI/oropNjKa8JsprKRG3dkCmU9M5peGqC9NudTzLlGajr9/kPlW 3bFFfQFKNRmORGD+Y3zLJOYBS2icMDAwXz+eBAYEeZqrSrJgUhR7T2FsJhdC+hA6fJkF8qUw Z6Xmz/a5PH1g1RWmmBAbGwXa4TCwOH06o+SXGmPwXh2eKfiv9xptWVbPiqORkXngTZxkmtoj n/2EX6hgto/uGrrJ3aE7r6V/bfoyvE77ycxBBNXps6cpNklEUffX3OO/67SPj9QLcvvIu6oA 1HQ0cypHBjaOJShpIgR4FAA1RwgYgRIJoRiBEhCVCJHzpTAgU6dvqaeG1r9KfJcLKXVmZSDW Nrz9nZbw/g6cwJ+//U2rFvEDTH/yYIB+yYZWAlMtiDoNJgQvmxhE6Dp4ORg8kwSsq5/P29bl h7OLqz18M7dI5/QKgtq5r4/PTt/vFQe3ljjJshOm1rs4Co4htDLsNPI1141WsU0hurG0b1qL +MCGqLF5bWEb8xqbamluM4cfDi4WC+Ty6qJTZGPy/Y8HF7rMIjL4CXVhgavOyeICSGFpISxw eXVwcl4qNSE6NhAkPGUrlOSmBbewqdOfrbfHZ28XMnTSPup8PFleDnW9vNRUgWU9Owhdmqhw B009XqmzYkVIHrUPOycHx/Oh8O747OBq/uujs49vj9tltE3w/86PbB5CR9Gwi44/jXrVBxFM OWxwJguaIOu5mMxX+ltweHjNdgJT/CtnkJNBy5WX0LPLzIZBDZAqktU2GTqZvVvgz+r8KSz7 gp4trejaLq+mqOeUio5NqN7VVBtqMivTTiqDjAvTMzXX3FHqjaKjC60WYpLRB+ncOcacGWSW nGjmLtF/VI79q4aNWQdUnDZ/CoBinHB2GADkMVHWMjCaFSyEOOXoKWuoHE9khUwOIMh9K+Tf L25ZqEKYYS+boRWvpXHwHfVcCH9kgh/XTfqlgFnEQRY+PywSUA4LkaD4YmcNPyjG2qEKldRe w3VvuEgU4bS/AEyKd917oFwBKKq7xNjBYCBD19CC1ISyQpmNKr5QfWSLwDXvgKbADsd3twgr QQgBgZkusxBXK4CsiK5lePrDw1kqtnUXYJFIPmFt9NF61SdE4sDw4+FtIgLnV3l2cEY0XgGS dwLlPFiKCVzOReaU8y7EwF8fArnZ2r8HB+78PAovyqqQIkHoqcVzq4FvckVjSy0EE8EwoW9R dr2QL59/1TmbMReqxVwGt2lBo5P5jJW6cLfJ/cM7SLUE9IFh8WeCoryo9SkggS3+nwFEYZHv wzu52V7uIQOd4hrlBcrLJDQ9sWZFXEstCouJrfhdIFsd/c8oxHxp931FiJRYgDMwvYo88xXm TxR6PaQ8C8vjqwi0lJMz8KNnI5co0XoQkRbW6f8zgrS4zeC+MGVaDyJVtX/gCRzqg0pTb3tY lihgmanST/ld41GcXbZ34y8XFt8jAJrckPJYIVAJEdzorChIPHoY9DjQ0DtxngQaD2sZs01E lcLXrPhTDudHUBhuc3pQZT2+omhn1uIMyRLvRSTu6bL0frwnNIK406/wZbjwoTmVwaBCvorM I+0XXE3kuq+fsG6lxRNgCIlbXjnxGy5xvJaf9RoKw6bltb53IxeMtpqgfmUZLeTCQjamjCV1 qZgBxnq6i70BtJn2DOgCjDfoVPvi4uxCN/vgw7S82Kfy0onsDrrL2nyM4Y4iVNtGHyF6/atC V/VYobf1Z8JXsbJG8ASCtzexVVobne2Mw838tPWON9EnUga0bRGDMZwdgiSD7BiLwt5x3ExQ 29xebVSoVPnTjgpCA32qLY2S+r/U7zRIEh4lRPXuo0VJQlFZbdCkfGBCvlzO/DMH2+yFZKZQ Xfv/PuZWGh/50QKPMUTEwq/B1UfAqrHkxKEJK+Irrzm9fHeNqmWoKh3p8Sigynl4pKlI+VSS SlOSuWlKTcsiYvecnGQfdB8x8VuUKu0x4e0ly5dh3Pmzed6rqc/muFc1rORqlnxdR87zrUPU w+L3cGrv7/tiJ//0PfEJHcbM7syv09PltMDU5+pi8dl4mSDRuFear/IGFfHpF2AW+YIoDQOs E/WcVgZ/qWf81GlvyOE7FcA1lqLTFLtfTaJBuyCq1qfCeV21zr9qbVU8r68XfFUloMtPUMD1 HCuRwAoTNCByXYkElNcUQDenZ6cz9VOwUpVVVKhT0JJaOlBZUap8ToG/M1etz6WLKNHfKatD RdfIqegPdVVp6PI5hezTVFUSWYWcRv4lpiqRvEZORWVmqpJQxcv1eU66CgmukSOPTBYT45h7 FWJcQxNTmC0FZqtQyyrlfeTvLlWJcOminvjDQHUtcfkCBZUqrkxBlS9QAJtduTaUzWqiazPJ wX2t6t63cTMlDhnpozK+tsqbhqeaxW2bluVGjmWRn6jVD4qnRqnt/Dw7P3orLgnEzXqtuOlx 2TZT5X5KG2HB3XWujA2ubPHmUSF2zOU9LPU16lrkjQl3vI24XpEG1E4HFn0kotpIJ+rNi7ga 5qzadPaUYiB/d5eOADEPgnVNiz1CUPQEhit5V3EUz7e4vLPW1CTVvSLAsxdAYKMCe0yAqqjq au8qEZjHgCpjqurqVhFICgSWcsAEkhIBJxhUZV8ToJPAYqViI5aDis1nBLAK176LTu3EUkcc 3odEtgfxPkQCezDAjAxLom8n/RUlgVVU7VTGoR2PV9EkpvXuroVEY2Dn2Mz+q83YLl6wZzNp HcFo4FkKm0d+QRnMEz5rLN/sz3v9+WlhKM6dx1nKcBZ2WPNK+3JypHh/M5r4Tk6nGHKm3cR7 PPuveI/n/xXvyX7lmXkmczNyOeivM0EwiXUmxb+QyMjl30igrpxMa5ZENauhHOUPswQnntvy ITvLYN7c8SB0/1MdZaGmkTcj/i4AVx3v3Nk7xjf02Ykb+uzEDX12YnmhwOIpaIF0Pc2PStRn ASZiOEBX90KdoWz72Xbh+JpP1ysvH6hHsT6bIy+yJzSzmlctab0eYNnO4W/VclsFo41MtuYc 0qtvIs5Izt4/rOfQ+lxPnXOZWvBQYM3A81pSgt5m4+4LHyY4m7PRt4bn6BWASOvolfM5bf80 z32b806saGnRl6hW2qf+MaR0OeBGHSGLRxhNnbg5/xiCUovqYAGdfph4N5WemHjPeSZ4WRqN E4U4I6hZyJkyiidClCuV8lbqTJMZqYf8LAwV6n2pqzdzwl4NcVM8L0S6ZIMoZAVr3OHDdbzf 1eHq+rMSn32dHZ5ubOIKn038qoQehs6S8lLVTGPq0BzdfiniVYccZwdW8qGOHPFSpEunmRTo Go1SQCs2mRk0yB4exFJ6xVUu1fcUfX9hj/KbUwoR8vsjGxMcWdFohIfDoG3mPtMWRpQPe6wX RkHaE0Z0QkGTGcOyOCbf5ge0NEg/E6/Pf776cHZqHZx3rB/bF5eds1PeoIIyIB6ZPeu9TI/g kcHcc5niUJqz2Vd3qkn2oa6T8udjJKa3Qqqy2CSMSC5plqhzewAo8Or6HDPAgnRusmAIxz+P 9TOHznl1jUZDmS/rnZ3aPlEy6o5N54NrZGYg1OKn4fJnH6a4vtbX+lpf62t9ra/1tb7W1/pa X+trfa2v9bW+1tf6Wl9/oet/AXuwADkAeAAA --h31gzZEtNLTqOjlF-- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From andrich@fga.de Mon Sep 29 19:09:54 1997 From: andrich@fga.de (Oliver Andrich) Date: Mon, 29 Sep 1997 20:09:54 +0200 Subject: [DB-SIG] Again a question about the API Message-ID: <19970929200954.52365@fga.de> Hi, I have nearly finished my new mysql module, and I am ready to do a first beta release quite soon. May be I will release a first version that still lacks some API conformance this night. But now back to my question concerning the API. I am currently working on the fetchmany, arraysize and description things. (The rest is already implemented and some more. ;-) But what do I means the following passage to me and what relevance has this for the API. "...Each 7-tuple contains information describing each result column: (name, type_code, display_size, internal_size, precision, scale, null_ok). ... Note: this is a bit in flux. Generelly, the first two items of the 7-tuple will be present; others may be database specific." Why do we need something like this description thing? I convert all the values returned by the database to native Python values as soon as you query the database. The only thing that well be misleading may timevalues and so on. So I see that this of importance for a good implementation, but for what is all after the typecode useful? Best regards, Oliver Andrich -- --------------------------------------------------------------------- FGA Furch & Graf intermediaservices gbr andrich@fga.de Gartenstr. 5 http://www.fga.de D-56220 Sankt Sebastian +49-261-98244-94 (voice) -95 (fax) --------------------------------------------------------------------- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Tue Sep 30 19:55:30 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Tue, 30 Sep 1997 11:55:30 -0700 Subject: [DB-SIG] Again a question about the API Message-ID: <0845FCDE78BFD011A17600805FD43A8F0108F4B3@RED-45-MSG.dns.microsoft.com> > From: Oliver Andrich [SMTP:andrich@fga.de] > Sent: Monday, September 29, 1997 11:10 AM > what do I means the following passage to me and what > relevance has this for the API. > > "...Each 7-tuple contains information describing each result column: > (name, > type_code, display_size, internal_size, precision, scale, null_ok). > ... Note: > this is a bit in flux. Generelly, the first two items of the 7-tuple > will be > present; others may be database specific." > > Why do we need something like this description thing? I convert all > the values > returned by the database to native Python values as soon as you query > the > database. > I can tell you why we put it there and what we use it for. Say you want to write a general-purpose table display or editing mechanism. You can execute (but not fetch) "select * from tablename" and then use the description to build a form, perform minor edit-checking, that sort of thing. M. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________