From anthony@computronix.com Thu Jan 3 20:39:37 2002 From: anthony@computronix.com (Anthony Tuininga) Date: Thu, 03 Jan 2002 13:39:37 -0700 Subject: [DB-SIG] cx_Oracle 2.4 Message-ID: <3C34C189.3020908@computronix.com> I am pleased to announce the availability of a new version of cx_Oracle, the Python interface to Oracle. New in this release: 1) String variables can now be made any length (previously restricted to the 64K limit imposed by Oracle for default binding); use the type cx_Oracle.LONG_STRING as the argument to setinputsizes() for binding in string values larger than 4000 bytes. 2) Raw and long raw columns are now supported; use the types cx_Oracle.BINARY and cx_Oracle.LONG_BINARY as the argument to setinputsizes() for binding in values of these types. 3) Functions DateFromTicks(), TimeFromTicks() and TimestampFromTicks() are now implemented. 4) Function cursor.setoutputsize() implemented 5) Added the ability to bind arrays as out parameters to procedures; use the format [cx_Oracle., ] as the input to the function setinputsizes() for binding arrays 6) Discovered from the Oracle 8.1.6 version of the documentation of the OCI libraries, that the size of the memory location required for the precision variable is larger than the printed documentation says; this was causing a problem with the code on the Sun platform. 7) Now support building RPMs for Linux (built on Red Hat Linux 7.2 but will likely work on other distributions) NOTE: As some of these things extend the DB API, comments are most welcome on whether this implementation is sensible! Anthony From anthony@computronix.com Fri Jan 4 18:29:46 2002 From: anthony@computronix.com (Anthony Tuininga) Date: Fri, 04 Jan 2002 11:29:46 -0700 Subject: [DB-SIG] cx_Oracle 2.4 Message-ID: <3C35F49A.2040001@computronix.com> My apologies for reposting this announcement, but I forgot one critical piece of information: the URL for downloading! http://www.computronix.com/utilities I am pleased to announce the availability of a new version of cx_Oracle, the Python interface to Oracle. New in this release: 1) String variables can now be made any length (previously restricted to the 64K limit imposed by Oracle for default binding); use the type cx_Oracle.LONG_STRING as the argument to setinputsizes() for binding in string values larger than 4000 bytes. 2) Raw and long raw columns are now supported; use the types cx_Oracle.BINARY and cx_Oracle.LONG_BINARY as the argument to setinputsizes() for binding in values of these types. 3) Functions DateFromTicks(), TimeFromTicks() and TimestampFromTicks() are now implemented. 4) Function cursor.setoutputsize() implemented 5) Added the ability to bind arrays as out parameters to procedures; use the format [cx_Oracle., ] as the input to the function setinputsizes() for binding arrays 6) Discovered from the Oracle 8.1.6 version of the documentation of the OCI libraries, that the size of the memory location required for the precision variable is larger than the printed documentation says; this was causing a problem with the code on the Sun platform. 7) Now support building RPMs for Linux (built on Red Hat Linux 7.2 but will likely work on other distributions) NOTE: As some of these things extend the DB API, comments are most welcome on whether this implementation is sensible! Anthony From Рейтинг Wed Jan 9 16:13:13 2002 From: Рейтинг (Рейтинг) Date: Wed, 9 Jan 2002 19:13:13 +0300 Subject: [DB-SIG] Приглашение! Message-ID: С РОЖДЕСТВОМ и НОВЫМ 2002 ГОДОМ !!!

Успехов, здоровья и удачи.

Приглашаем Вас посетить новую поисковую систему CarLine Best-Top и по желанию добавить свой ресурс в рейтинг CarLine Best-Top. Регистрация в нашей поисковой системе, это дополнительный шанс заявить о своем сайте многочисленной аудитории.

Все ресурсы, зарегистрированные в рейтинге CarLine Best-Top, автоматически заносятся в базу данных нашей поисковой системы.

Изюминка заключается в следующем:

После регистрации в рейтинге CarLine Best-Top, Вы можете дополнительно указать до 20 адресов непосредственно на любые документы Вашего ресурса. Наш робот отсканирует все документы по указанным адресам и соберет весь присутствующий текст в виде стандартного HTML-кода вместе с ссылками на все основные их страницы. Затем вся информация заносится в базу данных поисковой системы CarLine Best-Top.

Таким образом, Посетитель, введя запрос в "Поиске", получит результат в виде всех словосочетаний и слово-форм, хранящихся в нашей базе.

Наша цель - облегчение поиска информации любого направления.

Небольшой пример:

Допустим, Вам необходимо найти автосервис в г.Москва в районе ст. метро "Савеловская".

Ваши действия : На главной странице выбираете категорию Авто-мото > дальше раздел Автосервисы > выбираете
г. Москва > выбираете ст. метро "Савеловская" > Финиш. И так, Вы попали в раздел автосервисов, которые расположены около ст. метро "Савеловская".

Пока это только пример, но с Вашей помощью, по мере роста нашей базы, мы создадим эти подразделы.

Посетив нашу поисковую систему или добавив свой ресурс в рейтинг CarLine Best-Top,
мы ждем от Вас предложения по удобству навигации, создании новых разделов, подразделов.

Мы рассчитываем на Ваc!

Пожалуйста, примите наши самые глубочайшие извинения за затраченное Вами время, на чтение этого письма!

www.carline.ru

best-top@carline.ru From mal@lemburg.com Fri Jan 11 14:48:56 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 11 Jan 2002 15:48:56 +0100 Subject: [DB-SIG] ANN: eGenix.com mx COMMERCIAL Extension Package 2.0.4 for Python 2.2 Message-ID: <3C3EFB58.47AA35B8@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx COMMERCIAL Extension Package for Python Version 2.0.4 for Python 2.2 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mx COMMERCIAL Package for Python is part of the eGenix.com mx Extension Series for Python, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. This commercial package includes the popular mxODBC extension which allows users to connect from Python to just about any database on the market today, on Windows, Unix and Linux. By providing a consistent interface on all supported platforms, mxODBC serves as perfect base for writing cross-platform database programs and utilities. ________________________________________________________________________ WHAT'S NEW ? After having completed the tests, we have added binaries for Python 2.2 to the set of existing binaries. The package is now certified to work with Python 2.2 provided you have installed the latest eGenix.om mx BASE package (2.0.3) for Python 2.2 as well. Compatibility to Unicode-aware ODBC drivers such as the latest MS Access and MS SQL Server ODBC drivers was enhanced in mxODBC. It is now possible to exchange native Unicode data with these Unicode-capable databases using mxODBC. ________________________________________________________________________ SPECIAL OFFER theKompany.com has licensed the eGenix.com mx Commercial Package (which includes mxODBC) for inclusion in their brand new Qt-based Python IDE BlackAdder. It allows developing portable GUI-based database applications which run on Windows and Linux platforms without any change to the source code. BlackAdder includes a 1 CPU license for this package at no extra cost, so you may want to check out their great new product. See http://www.egenix.com/files/python/eGenix-mx-Extensions.html#BlackAdder for details. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.egenix.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.egenix.com/files/python/ Note that in order to use the eGenix.com mx COMMERCIAL package you will also need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? mxODBC comes with a licenses which allows non-commercial use at no charge, but places a moderate fee on commercial users. Special licensing setups are available for commercial product developers. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL for details. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ REFERENCE:

eGenix.com mx COMMERCIAL Package 2.0.4 for Python 2.2 - eGenix.com mx COMMERCIAL Interface 2.0.4 for Python 2.2 (11-Jan-2002) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From nicolas.torzec@rd.francetelecom.com Fri Jan 11 14:59:56 2002 From: nicolas.torzec@rd.francetelecom.com (TORZEC Nicolas thesard FTRD/DIH/LAN) Date: Fri, 11 Jan 2002 15:59:56 +0100 Subject: [DB-SIG] XML Databases and Python Message-ID: Dear all, I am currently involved in a project where I am using Python and where I manage (create /update /delete /select /use) many XML files. - My original idea was to create my own XML file managing system, but creating such a system will take a long time. - My second idea was to use a lightweight relationnal database, but it's not the easiest and the most efficient way to manipulate such semi-structured data - My third idea was to use a lightweight object-oriented database - My fourth idea was to use a lightweight native XML database What do you think about these solutions ? According to your Python/XML/Database experience, what is the most appropriate database type for this kind of job ? Do you know lightweight relationnal, object-oriented or XML oriented databases compatible with Python ? (preference is given to open source projects) Every advices are welcome :) Thank you in advance for your help, Nicolas PS : this message is posted on xml-sig and on db-sig. From daniel.dittmar@sap.com Fri Jan 11 15:12:32 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 11 Jan 2002 16:12:32 +0100 Subject: [DB-SIG] XML Databases and Python Message-ID: > Do you know lightweight relationnal, object-oriented or XML oriented > databases compatible with Python ? (preference is given to open source > projects) I haven't programmed either of them, but the following might work ZODB: http://www.amk.ca/zodb/ MetaKit: http://www.equi4.com/metakit/ Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From bkline@rksystems.com Fri Jan 11 15:29:02 2002 From: bkline@rksystems.com (Bob Kline) Date: Fri, 11 Jan 2002 10:29:02 -0500 (EST) Subject: [DB-SIG] XML Databases and Python In-Reply-To: Message-ID: On Fri, 11 Jan 2002, TORZEC Nicolas thesard FTRD/DIH/LAN wrote: > Dear all, > I am currently involved in a project where I am using Python and > where I manage (create /update /delete /select /use) many XML files. > > - My original idea was to create my own XML file managing system, but > creating such a system will take a long time. > - My second idea was to use a lightweight relationnal database, but it's not > the easiest and the most efficient way to manipulate such semi-structured > data > - My third idea was to use a lightweight object-oriented database > - My fourth idea was to use a lightweight native XML database > > > > What do you think about these solutions ? > According to your Python/XML/Database experience, what is the most > appropriate database type for this kind of job ? > Do you know lightweight relationnal, object-oriented or XML oriented > databases compatible with Python ? (preference is given to open source > projects) Hi, Nicolas. The choice we made for the project I'm currently working on for one of my clients was to use a relational database for the underlying storage mechanism. This allowed us to use the relational tables for managing and querying the document and system metadata. We store the XML in a single column of the master document table. We have tables for such things as user accounts, groups, and permissions, versioning of the documents, audit trails, inter-document link tracking, and element values for which XML Query is supported. We looked at the other solutions, which may be well suited to other projects, but concluded that for our purposes, at the time the architectural decisions were being made (back in 2000), this was the most appropriate. In particular we looked at the off-the-shelf SGML/XML repository management systems, and concluded that the tradeoffs between the amount of customization that would need to be done anyway, the uncertainties introduced by dependencies on third-parties in a rapidly evolving market, and the performance penalties introduced by at least some of the commercial approaches used by the commercial solutions, the customer would be better off if we built that piece ourselves. On the other hand, we evaluated and selected one of the commercially available XML editing packages (XMetaL from SoftQuad) for use as our primary front end (this didn't eliminate the need for heavy customization on the client end, though). The fact that we are using a standard DBMS underneath the repository means that we can take advantage of the richness of establish tools to work with the relational tables. We use Python heavily for much of our reporting (the parts that aren't handled well by XSL/T) and web-based administrative administrative tools. It's hard to find a good RDBMS with which Python is not compatible. As I say, this approach may not be the best for every XML repository, and we might not have made the same decisions after the commercial repository software has had a chance to mature further, but it's working well for us. Hope this is useful. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From arthuralbano@hotmail.com Fri Jan 11 03:56:01 2002 From: arthuralbano@hotmail.com (Arthur Albano) Date: Fri, 11 Jan 2002 12:56:01 +0900 Subject: [DB-SIG] XML, Python and, of course, DB's Message-ID: <000401c19a53$e2a5e310$77c5fea9@tokugawa> First of all, I would like to greet all. This is my first posting on Python even if I use it since 1.4. Databases can and will cause serious headaches on most programmers. Things that are always in my mind are: - Portability; - Stability; - Speed; - Scalability; - Flexibility. Among these, the most important to me is flexibility. I still believe that db solutions should be packed according to the clients needs and should adapt as fast as a lightning-bolt to new concepts and methods. I still believe that ui's should be on a browser and the server side has to bear the load of processing. The web proved that in the way that we have maps, encyclopedias, translations, books, etc. outside desktop computers. Many SQL server solutions are on the market but one that is really promising is the use of XML structured data, which is open and has various other advantages. Due to XML, user interface creation became simpler on multiplatform. But there is still a lack of, as far as I am aware of, database administration based on XML and Python. I believe this is the best solution to fit my needs (the things that are always in my mind). That's it, a lightweight object-oriented database and XML is my choice. So, python provides me with flexbility, and XML the open structure that I need. Arthur Albano "Just nobody." From bzimmer@ziclix.com Sun Jan 13 05:59:47 2002 From: bzimmer@ziclix.com (brian zimmer) Date: Sat, 12 Jan 2002 23:59:47 -0600 Subject: [DB-SIG] Extensions to DB API 2.0 In-Reply-To: <3BFE332B.F80A9248@lemburg.com> Message-ID: <000001c19bf7$8508ac10$6401a8c0@mountain> > Cursor Method .scroll(value[,mode='relative']) > > Scroll the cursor in the result set to a new position according > to mode. > > If mode is 'relative' (default), value is taken as offset to > the current position in the result set, if set to 'absolute', > value states an absolute target position. > > An IndexError should be raised in case a scroll operation would > leave the result set. In this case, the cursor position is left > undefined (ideal would be to not move the cursor at all). > > Note: This method should use native scrollable cursors, if > available , or revert to an emulation for forward-only > scrollable cursors. The method may raise NotSupportedErrors to > signal that a specific operation is not supported by the > database (e.g. backward scrolling). > > Warning Message: "DB-API extension cursor.scroll() used" In implementing .scroll() for zxJDBC the underlying JDBC result set's absolute scrolling allows for negative numbers for value. The result set then counts backwards from the end of the set much like a Python sequence. I was wondering if the DB API .scroll() supported the same semantics? What should happen for .scroll(-1, "absolute")? Is this an IndexError or does .rownumber become the last row in the result set? thanks, brian From daniel.dittmar@sap.com Mon Jan 14 00:06:18 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 14 Jan 2002 01:06:18 +0100 Subject: [DB-SIG] Proposal: model database metadata from JDBC Message-ID: I would like to propose that any metadata facilities for the Python DB API follow the interface specified by JDBC:DatabaseMetadata: http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html Advantages: - covers a lot of ground - can be easily tested (depending on the quality of the JDBC driver) The archive http://home.snafu.de/~dittmar/downloads/genMetadataClass.tgz contains a python script which generates such a class complete with doc strings (well, javadoc strings). If a JDBC driver is available and the script is executed using Jython, then some of the methods are generated using information from the JDBC driver. Of course, using ODBC as a model would have the same advantages. Perhaps someone with some knowledge of ODBC and some time could write a similar script. I haven't really looked into the ODBC documentation, but as I use in the SAP DB JDBC driver the same views the ODBC driver uses, I guess the two API are quite close in functionality. Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin mailto:daniel.dittmar@sap.com http://www.sapdb.org/ From fog@initd.org Mon Jan 14 00:15:46 2002 From: fog@initd.org (Federico Di Gregorio) Date: 14 Jan 2002 01:15:46 +0100 Subject: [DB-SIG] Proposal: model database metadata from JDBC In-Reply-To: References: Message-ID: <1010967347.15010.27.camel@nenya> --=-oO2aLPJTqoHzTtPt21Aq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il lun, 2002-01-14 alle 01:06, Dittmar, Daniel ha scritto: > I would like to propose that any metadata facilities for the Python=20 > DB API follow the interface specified by JDBC:DatabaseMetadata: > http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html i don't want to start a python vs java flame here, but you seem to suppose that a java api is good by itself (i myself consider java a api-bloated language...)=20 can you please elaborate on "metadata facilities" and why such an interface would be good? federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer --=-oO2aLPJTqoHzTtPt21Aq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Per informazioni si veda http://www.gnupg.org iEYEABECAAYFAjxCIzEACgkQvcCgrgZGjevzigCbBMIMRLxW8zqD53w9OkyY9C3r 1/UAnizRc+0/rFXa1fDnxPl0I3B7Dywq =hQ/Q -----END PGP SIGNATURE----- --=-oO2aLPJTqoHzTtPt21Aq-- From bzimmer@ziclix.com Mon Jan 14 00:40:02 2002 From: bzimmer@ziclix.com (brian zimmer) Date: Sun, 13 Jan 2002 18:40:02 -0600 Subject: [DB-SIG] Proposal: model database metadata from JDBC In-Reply-To: <1010967347.15010.27.camel@nenya> Message-ID: <001501c19c94$03ddb980$6401a8c0@mountain> While mimicing the Java DatabaseMetaData would make things trivial for me I don't think it makes a very pythonic interface. I have chosen to copy mxODBC's extensions (such as .tables, .columns, .procedures, etc) when implementing my own extensions for zxJDBC. I have exposed a lot of the DatabaseMetaData and think a feature such as it is invaluable, but I wouldn't want to see it copied straight away. Instead, I'd rather see the following (as copied from mxODBC and extended by me): The name in parens is the DMD method name. It's much easier just to cross reference with that but I've included a short description nonetheless. tables (getTables) - a list of all tables columns (getColumns) - a list of all columns for a table primarykeys (getPrimaryKeys) - the primary keys for a table foreignkeys (getCrossReference) - the foreign keys for a table as well as keys imported by other tables procedures (getProcedures) - a list of all procedures procedurecolumns (getProcedureColumns) - description of a procedure's columns statistics (getIndexInfo) - description of a table's indices and statistics bestrow (getBestRowIdentifier) - optimal set of columns that uniquely identifies a row versioncolumns (getVersionColumns) - columns that are automatically updated when any value in a row is updated typeinfo (getTypeInfo) - a list of all available datatypes One thing I've found while getting zxJDBC to work across all databases is the case of the values, in particular table and procedure names, can be tricky. It would also be useful therefore to include information about how a particular database stores table and other such names. I've also found that not all drivers are created equal and given the number of methods needed to implement the entire DatabaseMetaData interface some corners are cut and not all the methods are tested. I think it would be best to start with the most useful and add as needed. Just my $0.02 thanks, brian > -----Original Message----- > From: db-sig-admin@python.org > [mailto:db-sig-admin@python.org] On Behalf Of Federico Di Gregorio > Sent: Sunday, January 13, 2002 6:16 PM > To: 'db-sig@python.org' > Subject: Re: [DB-SIG] Proposal: model database metadata from JDBC > > > Il lun, 2002-01-14 alle 01:06, Dittmar, Daniel ha scritto: > > I would like to propose that any metadata facilities for the Python > > DB API follow the interface specified by JDBC:DatabaseMetadata: > > http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html > > i don't want to start a python vs java flame here, but you > seem to suppose that a java api is good by itself (i myself > consider java a api-bloated language...) > > can you please elaborate on "metadata facilities" and why > such an interface would be good? > > federico > > -- > Federico Di Gregorio > Debian GNU/Linux Developer & Italian Press Contact > fog@debian.org > INIT.D Developer > fog@initd.org > God is real. Unless declared integer. -- Anonymous FORTRAN > programmer > From mal@lemburg.com Mon Jan 14 09:30:54 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 14 Jan 2002 10:30:54 +0100 Subject: [DB-SIG] Extensions to DB API 2.0 References: <000001c19bf7$8508ac10$6401a8c0@mountain> Message-ID: <3C42A54E.8B4B8E11@lemburg.com> brian zimmer wrote: > > > Cursor Method .scroll(value[,mode='relative']) > > > > Scroll the cursor in the result set to a new position according > > to mode. > > > > If mode is 'relative' (default), value is taken as offset to > > the current position in the result set, if set to 'absolute', > > value states an absolute target position. > > > > An IndexError should be raised in case a scroll operation would > > leave the result set. In this case, the cursor position is left > > undefined (ideal would be to not move the cursor at all). > > > > Note: This method should use native scrollable cursors, if > > available , or revert to an emulation for forward-only > > scrollable cursors. The method may raise NotSupportedErrors to > > signal that a specific operation is not supported by the > > database (e.g. backward scrolling). > > > > Warning Message: "DB-API extension cursor.scroll() used" > > In implementing .scroll() for zxJDBC the underlying JDBC result set's > absolute scrolling allows for negative numbers for value. The result > set then counts backwards from the end of the set much like a Python > sequence. I was wondering if the DB API .scroll() supported the same > semantics? What should happen for .scroll(-1, "absolute")? Is this an > IndexError or does .rownumber become the last row in the result set? Good question. In mxODBC I have implemented the Python sequence indexing semantics, but this feature is only available if the database provides the .rownumber information (and not all databases do). I'd say, we leave this undefined so it becomes an implementation detail. The IndexError is really meant for relative moving in the result set. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From andy47@halfcooked.com Mon Jan 14 09:51:18 2002 From: andy47@halfcooked.com (Andy Todd) Date: Mon, 14 Jan 2002 20:51:18 +1100 Subject: [DB-SIG] Proposal: model database metadata from JDBC References: <001501c19c94$03ddb980$6401a8c0@mountain> Message-ID: <3C42AA16.5070308@halfcooked.com> Whilst it is not the purpose of the application, perhaps you should look at dbdoc (http://dbdoc.sourceforge.net/). This implements a standard API which is then used to query the metadata in a database and produce html documentation from it. I mention it because the API has some similarities with the DMD methods mentioned below. Experience also tells me that getting a common metadata set is very difficult. dbdoc works with Oracle and PostgreSQL and just implementing those two engines has involved a lot of compromise. I've started porting the API to MySQL and that is just a nightmare. I'm not trying to be negative though, just realistic. I'm interested to see which RDBMS the java interface supports. That would provide a guideline of the possible, rather than the ideal. brian zimmer wrote: > While mimicing the Java DatabaseMetaData would make things trivial for > me I don't think it makes a very pythonic interface. I have chosen to > copy mxODBC's extensions (such as .tables, .columns, .procedures, etc) > when implementing my own extensions for zxJDBC. I have exposed a lot of > the DatabaseMetaData and think a feature such as it is invaluable, but I > wouldn't want to see it copied straight away. Instead, I'd rather see > the following (as copied from mxODBC and extended by me): > > The name in parens is the DMD method name. It's much easier just to > cross reference with that but I've included a short description > nonetheless. > > tables (getTables) > - a list of all tables > > columns (getColumns) > - a list of all columns for a table > > primarykeys (getPrimaryKeys) > - the primary keys for a table > > foreignkeys (getCrossReference) > - the foreign keys for a table as well as keys imported by other tables > > procedures (getProcedures) > - a list of all procedures > > procedurecolumns (getProcedureColumns) > - description of a procedure's columns > > statistics (getIndexInfo) > - description of a table's indices and statistics > > bestrow (getBestRowIdentifier) > - optimal set of columns that uniquely identifies a row > > versioncolumns (getVersionColumns) > - columns that are automatically updated when any value in a row is > updated > > typeinfo (getTypeInfo) > - a list of all available datatypes > > One thing I've found while getting zxJDBC to work across all databases > is the case of the values, in particular table and procedure names, can > be tricky. It would also be useful therefore to include information > about how a particular database stores table and other such names. > > I've also found that not all drivers are created equal and given the > number of methods needed to implement the entire DatabaseMetaData > interface some corners are cut and not all the methods are tested. I > think it would be best to start with the most useful and add as needed. > > Just my $0.02 > > thanks, > > brian > > >>-----Original Message----- >>From: db-sig-admin@python.org >>[mailto:db-sig-admin@python.org] On Behalf Of Federico Di Gregorio >>Sent: Sunday, January 13, 2002 6:16 PM >>To: 'db-sig@python.org' >>Subject: Re: [DB-SIG] Proposal: model database metadata from JDBC >> >> >>Il lun, 2002-01-14 alle 01:06, Dittmar, Daniel ha scritto: >> >>>I would like to propose that any metadata facilities for the Python >>>DB API follow the interface specified by JDBC:DatabaseMetadata: >>>http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html >>> >>i don't want to start a python vs java flame here, but you >>seem to suppose that a java api is good by itself (i myself >>consider java a api-bloated language...) >> >>can you please elaborate on "metadata facilities" and why >>such an interface would be good? >> >>federico >> >>-- >>Federico Di Gregorio >>Debian GNU/Linux Developer & Italian Press Contact >>fog@debian.org >>INIT.D Developer >>fog@initd.org >> God is real. Unless declared integer. -- Anonymous FORTRAN >>programmer >> >> > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > > > Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "Another year older, still no wiser." - Me, on my birthday From mal@lemburg.com Mon Jan 14 10:16:41 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 14 Jan 2002 11:16:41 +0100 Subject: [DB-SIG] Proposal: model database metadata from JDBC References: Message-ID: <3C42B009.59944B75@lemburg.com> "Dittmar, Daniel" wrote: > > I would like to propose that any metadata facilities for the Python > DB API follow the interface specified by JDBC:DatabaseMetadata: > http://java.sun.com/j2se/1.4/docs/api/java/sql/DatabaseMetaData.html > > Advantages: > - covers a lot of ground > - can be easily tested (depending on the quality of the JDBC driver) > > The archive http://home.snafu.de/~dittmar/downloads/genMetadataClass.tgz > contains a python script which generates such a class complete with doc > strings (well, javadoc strings). If a JDBC driver is available and the > script is executed using Jython, then some of the methods are generated > using information from the JDBC driver. > > Of course, using ODBC as a model would have the same advantages. Perhaps > someone with some knowledge of ODBC and some time could write a similar > script. I haven't really looked into the ODBC documentation, but as I > use in the SAP DB JDBC driver the same views the ODBC driver uses, I > guess the two API are quite close in functionality. JDBC was modelled after ODBC, so all information available in JDBC is also available in ODBC (early JDBC drivers were really only thin wrappers around existing ODBC drivers). Since JDBC was designed much later, it doesn't suffer of all the problems that ODBC has though and in general, I think that the JDBC interface has a much better design than ODBC's convoluted structure. About the interface: I suppose we could develop a JDBC like interface on top of the existing DB API. The class would not have to be generated though, but instead get it's information from a passed in connection object. Database module wanting to support this interface would then have to define a DatabaseMetaData class at module level and users could then instantiate it with connection objects. How does that sound ? Later on, we might extend this wrapper to cover more of the JDBC interface as front-end to the various databases out there. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.dittmar@sap.com Mon Jan 14 13:40:36 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 14 Jan 2002 14:40:36 +0100 Subject: [DB-SIG] Proposal: model database metadata from JDBC Message-ID: > From: Federico Di Gregorio [mailto:fog@initd.org] > i don't want to start a python vs java flame here, but you seem to > suppose that a java api is good by itself (i myself consider java a > From: brian zimmer [mailto:bzimmer@ziclix.com] > I think it would be best to start with the most useful and add > as needed. It was my main intention to implement the stuff once and then forget about it. That's why I choose a rather largish API. If some consider the stuff in mxODBC to be mote pythonic, that's fine with me too. It already has two working implemtations, and as these are ODBC and JDBC wrappers, they can be used as a reference protocol for the native implementations. Having a full API would also be a boon to developers of IDEs and development tools (From Any Todd's mail: "Experience also tells me that getting a common metadata set is very difficult.") and those mentoring VB and Java refugees ("I can do this in VB. Why can't I do it in Python?") It might be good idea to split the interface into two: - catalog information (tables, columns, procedures etc.) - database capabilities (identifier format, isolation levels etc.) The latter is really static and can be generated from a JDBC driver. The former requires some knowledge of the system tables. Whether the resulting cursors are passed directly to the application or are filtered into Python objects isn't that much of a difference for the driver developer. > From: M.-A. Lemburg [mailto:mal@lemburg.com] > About the interface: I suppose we could develop a JDBC like > interface on top of the existing DB API. The class would not > have to be generated though, but instead get it's information > from a passed in connection object. > > Database module wanting to support this interface would then > have to define a DatabaseMetaData class at module level > and users could then instantiate it with connection objects. That was my intent. The code generator I mentioned is used only: - to save some typing of the method signatures and the doc strings (and to get easier updates should we decide on some default parameters or another doc string format) - to get the 'database capabilities' automatically from a JDBC driver. Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From mal@lemburg.com Tue Jan 15 10:03:03 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 15 Jan 2002 11:03:03 +0100 Subject: [DB-SIG] Proposal: model database metadata from JDBC References: <001501c19c94$03ddb980$6401a8c0@mountain> <3C42AA16.5070308@halfcooked.com> Message-ID: <3C43FE57.B12EC1CC@lemburg.com> Andy Todd wrote: > > Whilst it is not the purpose of the application, perhaps you should look > at dbdoc (http://dbdoc.sourceforge.net/). > > This implements a standard API which is then used to query the metadata > in a database and produce html documentation from it. I mention it > because the API has some similarities with the DMD methods mentioned below. > > Experience also tells me that getting a common metadata set is very > difficult. dbdoc works with Oracle and PostgreSQL and just implementing > those two engines has involved a lot of compromise. I've started porting > the API to MySQL and that is just a nightmare. > > I'm not trying to be negative though, just realistic. I'm interested to > see which RDBMS the java interface supports. That would provide a > guideline of the possible, rather than the ideal. Since most DBs support ODBC, the meta information should be (more or less) available. ODBC drivers usually map the catalog methods to SELECTs on internal DB tables and hard-code the various other feature flags. For MySQL, a good source of meta-data is the MyODBC driver source code. It provides all of the above APIs and maps them to MySQL internal queries. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From neutron@cayuse.net Sat Jan 19 00:40:54 2002 From: neutron@cayuse.net (Ricardo Ortega) Date: Fri, 18 Jan 2002 19:40:54 -0500 Subject: [DB-SIG] test Message-ID: <000101c1a081$f70d8bd0$e1481342@NEUTRONXP> This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C1A058.0E3783D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit test ------=_NextPart_000_0002_01C1A058.0E3783D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

test

------=_NextPart_000_0002_01C1A058.0E3783D0-- From jim@zope.com Sat Jan 26 00:30:20 2002 From: jim@zope.com (Jim Fulton) Date: Fri, 25 Jan 2002 19:30:20 -0500 Subject: [DB-SIG] ANNOUNCE: Python 10 Birds of a Feather session on a Python persistence framework Message-ID: <3C51F89C.3A35E4A9@zope.com> We plan to have a Birds of a Feather (BOF) session at the Python 10 Conference, http://python10.org, on a Python persistence framework. The Zope object database, ZODB, includes frameworks for persistence and transaction management. These frameworks depend very little on the rest of ZODB and will be factored out of ZODB and made into separate packages in the next generation of ZODB, ZODB 4. The ZODB persistence framework provides significant benefits to Python programmers: - Objects are automatically loaded and stored. The programmer doesn't have to keep tack of when objects have been modified. The objects track modification and notify the transaction manager of changes. The transaction manager coordinates storing data. Data are loaded when needed, with loads triggered by access from other objects. - An object cache automates moving data out of memory when no longer needed. A cache invalidation protocol helps to keep object consistence across multiple applications or application threads. We would like to see these benefits made available for other databases. We'd especially like to see a persistence framework using relational databases, reusing object-relational mapping efforts, such as MiddleKit and others. We'd like to kick off an effort to design a persistence framework to encompass ZODB, relational databases, and other persistence systems. The BOF will begin with a presentation of the ZODB Persistence framework. The BOF will take place the evening of Wednesday, February 6. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From jim@zope.com Sat Jan 26 00:31:52 2002 From: jim@zope.com (Jim Fulton) Date: Fri, 25 Jan 2002 19:31:52 -0500 Subject: [DB-SIG] ANNOUNCE: Python 10 Birds of a Feather session on a Python distributed transaction framework Message-ID: <3C51F8F8.71613AE5@zope.com> We plan to have a Birds of a Feather (BOF) session at the Python 10 Conference, http://python10.org, on a Python distributed transaction framework. The Zope object database, ZODB, includes frameworks for persistence and transaction management. These frameworks depend very little on the rest of ZODB and will be factored out of ZODB and made into separate packages in the next generation of ZODB, ZODB 4. We have experience using the transaction framework with other persistence mechanisms in Zope, including relational databases and the light-weight directory access protocol, LDAP. This allows distributed transactions to be coordinated among multiple database systems. If a transaction is committed or rolled back, the commit or rollback happens for each of the participating databases. This is very useful. It would be useful to make this capability available to other Python applications. In particular, it would be worthwhile to explore integrating distributed transactions with the Python database API to make it easier to coordinate among multiple databases and to better support distributed transactions in the Python database API, for example by including interfaces to underlying distributed-transaction APIs not currently exposed by the Python database API. We'd like to kick off an effort to design a transaction framework to encompass ZODB, relational databases, and other persistence systems. The talk BOF begin with a presentation of the ZODB Transaction framework. The BOF will take place at lunch time on Tuesday, February 5. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From mal@lemburg.com Sat Jan 26 11:58:55 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 26 Jan 2002 12:58:55 +0100 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> Message-ID: <3C5299FF.94A1B555@lemburg.com> Jim Fulton wrote: > > We plan to have a Birds of a Feather (BOF) session at the Python 10 > Conference, http://python10.org, on a Python distributed transaction > framework. > > The Zope object database, ZODB, includes frameworks > for persistence and transaction management. These frameworks > depend very little on the rest of ZODB and will be factored > out of ZODB and made into separate packages in the next generation > of ZODB, ZODB 4. > > We have experience using the transaction framework > with other persistence mechanisms in Zope, including relational > databases and the light-weight directory access protocol, LDAP. > This allows distributed transactions to be coordinated among > multiple database systems. If a transaction is committed or rolled > back, the commit or rollback happens for each of the participating > databases. This is very useful. It would be useful to make this > capability available to other Python applications. Agreed... even though it will be hard to force this: e.g. an application might call .commit() on a database connection without the transaction manager knowing about it -- there's no way to find out whether a transaction is still active or not (databases hide this very well from programs using the database interface), so the transaction manager will run into problems when trying to rollback the last transaction it started. > In particular, it would be worthwhile to explore integrating > distributed transactions with the Python database API to make it > easier to coordinate among multiple databases and to better support > distributed transactions in the Python database API, for example by > including interfaces to underlying distributed-transaction APIs not > currently exposed by the Python database API. The DB API already exposes .commit() and .rollback(). What other APIs do you have in mind here ? > We'd like to kick off an effort to design a transaction framework > to encompass ZODB, relational databases, and other persistence > systems. > > The talk BOF begin with a presentation of the ZODB Transaction > framework. > > The BOF will take place at lunch time on Tuesday, February 5. I won't make it to the conference; could you put up a summary of your findings somewhere on the net ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jim@zope.com Mon Jan 28 14:15:00 2002 From: jim@zope.com (Jim Fulton) Date: Mon, 28 Jan 2002 09:15:00 -0500 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> Message-ID: <3C555CE4.DCE62EE0@zope.com> "M.-A. Lemburg" wrote: > ... > The DB API already exposes .commit() and .rollback(). What other > APIs do you have in mind here ? These are non-distributed APIs. Many databases have separate APIs to support distributed transactions, typically conforming to the X/Open XA distributed transaction standard. Unfortunately, the APIs aren't part of the DB API. We should consider adding these. > > We'd like to kick off an effort to design a transaction framework > > to encompass ZODB, relational databases, and other persistence > > systems. > > > > The talk BOF begin with a presentation of the ZODB Transaction > > framework. > > > > The BOF will take place at lunch time on Tuesday, February 5. > > I won't make it to the conference; I'm sorry to hear that. > could you put up a summary > of your findings somewhere on the net ? Of course. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From mal@lemburg.com Mon Jan 28 16:41:47 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 28 Jan 2002 17:41:47 +0100 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> <3C555CE4.DCE62EE0@zope.com> Message-ID: <3C557F4B.37962FFC@lemburg.com> Jim Fulton wrote: > > "M.-A. Lemburg" wrote: > > > ... > > > The DB API already exposes .commit() and .rollback(). What other > > APIs do you have in mind here ? > > These are non-distributed APIs. Many databases have separate > APIs to support distributed transactions, typically conforming to > the X/Open XA distributed transaction standard. Unfortunately, the > APIs aren't part of the DB API. We should consider adding these. Hmm, the only references to databases and repositories supporting these APIs I could find are related to object databases and distributed relational database scenarios. Perhaps we ought to come up with a standard for XA-compliant transaction managers instead ?! OTOH, there's nothing much to invent here, since the XA standard already defines the interfaces: http://www.opengroup.org/dbiop/s423.pdf or for a broader view of things: http://www.opengroup.org/dbiop/index.htm The only problem I see with this is that DB API modules (the resource managers or RM in XA terms) need to be made aware of the transaction manager (TM) in some way (e.g. to prevent accidental .commit() or .rollback() calls within the DB API module and to report errors which might invoke error handling in the TM). Also, DB API modules will sometimes have to be careful about their internal setup (e.g. set the drivers they wrap to single threading mode and/or initialize it for two phase commit). > > > We'd like to kick off an effort to design a transaction framework > > > to encompass ZODB, relational databases, and other persistence > > > systems. > > > > > > The talk BOF begin with a presentation of the ZODB Transaction > > > framework. > > > > > > The BOF will take place at lunch time on Tuesday, February 5. > > > > I won't make it to the conference; > > I'm sorry to hear that. > > > could you put up a summary > > of your findings somewhere on the net ? > > Of course. Great. I'd suggest to use the PEP format as basis since it integrates nicely with the tools we have available for handling these. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jim@zope.com Mon Jan 28 16:54:22 2002 From: jim@zope.com (Jim Fulton) Date: Mon, 28 Jan 2002 11:54:22 -0500 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> <3C555CE4.DCE62EE0@zope.com> <3C557F4B.37962FFC@lemburg.com> Message-ID: <3C55823E.256ABE74@zope.com> "M.-A. Lemburg" wrote: > > Jim Fulton wrote: > > > > "M.-A. Lemburg" wrote: > > > > > ... > > > > > The DB API already exposes .commit() and .rollback(). What other > > > APIs do you have in mind here ? > > > > These are non-distributed APIs. Many databases have separate > > APIs to support distributed transactions, typically conforming to > > the X/Open XA distributed transaction standard. Unfortunately, the > > APIs aren't part of the DB API. We should consider adding these. > > Hmm, the only references to databases and repositories supporting > these APIs I could find are related to object databases and > distributed relational database scenarios. BerkeleyDB supports XA. I'm pretty sure Oracle does too. ... > > > could you put up a summary > > > of your findings somewhere on the net ? > > > > Of course. > > Great. I'd suggest to use the PEP format as basis since it integrates > nicely with the tools we have available for handling these. Good idea. So the ultimate product of this BOF (and the Persistence BOF) should be a PEP. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From mal@lemburg.com Tue Jan 29 10:59:40 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 29 Jan 2002 11:59:40 +0100 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> <3C555CE4.DCE62EE0@zope.com> <3C557F4B.37962FFC@lemburg.com> <3C55823E.256ABE74@zope.com> Message-ID: <3C56809C.31CDBAFF@lemburg.com> Jim Fulton wrote: > > > > > The DB API already exposes .commit() and .rollback(). What other > > > > APIs do you have in mind here ? > > > > > > These are non-distributed APIs. Many databases have separate > > > APIs to support distributed transactions, typically conforming to > > > the X/Open XA distributed transaction standard. Unfortunately, the > > > APIs aren't part of the DB API. We should consider adding these. > > > > Hmm, the only references to databases and repositories supporting > > these APIs I could find are related to object databases and > > distributed relational database scenarios. > > BerkeleyDB supports XA. I'm pretty sure Oracle does too. I read about support in IBM's DB2 -- as I read it, there are basically two options: 1. You let DB2 play the role of the transcation manager . In that case, there are no APIs to be called -- the database works out the transactions itself. You only have watch out to setup the database driver accordingly (e.g. disable thread support in the driver, tell it to do two-phase commits, etc.). 2. You use a per-process transaction manager (TM). This scenario is similar to 1. in that you have to setup the database driver in the same way. The mayor difference here is that you have to use the TM's transaction API .commit() and .rollback() instead of the database driver ones. The first option does not expose any APIs to the user. The second depends on the used use TM, but also requires a lot of extra application awareness in order to work. It doesn't look like a framework would help a lot to make this easier to setup... Perhaps what you really want here is a central data source management object within a Python process. All database activitiy would then be managed by this instance and it could also implement XA style coupled transactions ?! I'm using something like this in the eGenix Application Server to implement coupled transcations and it works great. The main idea is to use the management object's .commit() and .rollback() APIs instead of the connection object ones. Of course, there may be other scenarios where it is not feasable to couple *all* transactions. To handle such a case, we'd need something more XA like in order to couple various transactions into a single logical entity. > ... > > > > > could you put up a summary > > > > of your findings somewhere on the net ? > > > > > > Of course. > > > > Great. I'd suggest to use the PEP format as basis since it integrates > > nicely with the tools we have available for handling these. > > Good idea. So the ultimate product of this BOF (and the Persistence > BOF) should be a PEP. Right. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From jim@zope.com Tue Jan 29 14:41:05 2002 From: jim@zope.com (Jim Fulton) Date: Tue, 29 Jan 2002 09:41:05 -0500 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> <3C555CE4.DCE62EE0@zope.com> <3C557F4B.37962FFC@lemburg.com> <3C55823E.256ABE74@zope.com> <3C56809C.31CDBAFF@lemburg.com> Message-ID: <3C56B481.43FADAC8@zope.com> "M.-A. Lemburg" wrote: > > Jim Fulton wrote: > > > > > > > The DB API already exposes .commit() and .rollback(). What other > > > > > APIs do you have in mind here ? > > > > > > > > These are non-distributed APIs. Many databases have separate > > > > APIs to support distributed transactions, typically conforming to > > > > the X/Open XA distributed transaction standard. Unfortunately, the > > > > APIs aren't part of the DB API. We should consider adding these. > > > > > > Hmm, the only references to databases and repositories supporting > > > these APIs I could find are related to object databases and > > > distributed relational database scenarios. > > > > BerkeleyDB supports XA. I'm pretty sure Oracle does too. > > I read about support in IBM's DB2 -- as I read it, there are basically > two options: > > 1. You let DB2 play the role of the transcation manager . In that > case, there are no APIs to be called -- the database works out > the transactions itself. You only have watch out to setup the > database driver accordingly (e.g. disable thread support in the > driver, tell it to do two-phase commits, etc.). This is pretty pointless if your goal is distributes transactions. > 2. You use a per-process transaction manager (TM). This scenario is > similar to 1. in that you have to setup the database driver in > the same way. The mayor difference here is that you have to > use the TM's transaction API .commit() and .rollback() instead > of the database driver ones. Do they support third-party transaction monitors? ... > Perhaps what you really want here is a central data source management > object within a Python process. All database activitiy would then be > managed by this instance and it could also implement XA style coupled > transactions ?! Something like that. It should support multiple simultaneous transactions within a process. > I'm using something like this in the eGenix Application > Server to implement coupled transcations and it works great. The > main idea is to use the management object's .commit() and .rollback() > APIs instead of the connection object ones. Of course, there may > be other scenarios where it is not feasable to couple *all* > transactions. I'm not sure what you mean here. Did you mean to say resource managers? > To handle such a case, we'd need something more XA > like in order to couple various transactions into a single > logical entity. You lost me. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From mal@lemburg.com Tue Jan 29 18:02:23 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 29 Jan 2002 19:02:23 +0100 Subject: [DB-SIG] Distributed Transaction framework References: <3C51F8F8.71613AE5@zope.com> <3C5299FF.94A1B555@lemburg.com> <3C555CE4.DCE62EE0@zope.com> <3C557F4B.37962FFC@lemburg.com> <3C55823E.256ABE74@zope.com> <3C56809C.31CDBAFF@lemburg.com> <3C56B481.43FADAC8@zope.com> Message-ID: <3C56E3AF.A0894D16@lemburg.com> Jim Fulton wrote: > > > > BerkeleyDB supports XA. I'm pretty sure Oracle does too. > > > > I read about support in IBM's DB2 -- as I read it, there are basically > > two options: > > > > 1. You let DB2 play the role of the transcation manager . In that > > case, there are no APIs to be called -- the database works out > > the transactions itself. You only have watch out to setup the > > database driver accordingly (e.g. disable thread support in the > > driver, tell it to do two-phase commits, etc.). > > This is pretty pointless if your goal is distributes transactions. Not really: this setup is for connecting to more than one DB2 database and then coupling the transactions for the two or more connections. > > 2. You use a per-process transaction manager (TM). This scenario is > > similar to 1. in that you have to setup the database driver in > > the same way. The mayor difference here is that you have to > > use the TM's transaction API .commit() and .rollback() instead > > of the database driver ones. > > Do they support third-party transaction monitors? Yes, MS TM on Win NT and two other on mainframes (can't remember the names). > ... > > > > Perhaps what you really want here is a central data source management > > object within a Python process. All database activitiy would then be > > managed by this instance and it could also implement XA style coupled > > transactions ?! > > Something like that. It should support multiple simultaneous transactions > within a process. > > > I'm using something like this in the eGenix Application > > Server to implement coupled transcations and it works great. The > > main idea is to use the management object's .commit() and .rollback() > > APIs instead of the connection object ones. Of course, there may > > be other scenarios where it is not feasable to couple *all* > > transactions. > > I'm not sure what you mean here. Did you mean to say > resource managers? Well, you normally connect to different data sources (resource manager in XA terms) and then have to deal with the problem of how to handle errors which cause the HTTP request to fail. I suppose you have the same problem in Zope. For these applications, things are easy to manage: you simply issue a rollback on all open connections. However, there may be other applications such as GUI applciations which use multiple data sources, but in different scopes, e.g. the application could have a set of system internal connections to various data sources and another set of user data specific connections. In such a scenario you would want to couple the user data connections only and leave the system internal connections alone. > > To handle such a case, we'd need something more XA > > like in order to couple various transactions into a single > > logical entity. > > You lost me. :) Oops :-) Example: Say you have data sources A, B, C, D. Now it may be feasable for your application to couple transactions on sources A and B only, while leaving the transactions in C and D uncoupled. In case of an error, you'd only rollback A and B. C and D would not see the rollback. A typical case is where A and B are connections to databases which you need to update, while C and D are read-only databases. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/