From gh at ghaering.de Tue Mar 3 11:05:16 2009 From: gh at ghaering.de (=?ISO-8859-1?Q?Gerhard_H=E4ring?=) Date: Tue, 03 Mar 2009 11:05:16 +0100 Subject: [DB-SIG] [ANN] pysqlite 2.5.2 Message-ID: <49AD00DC.5010005@ghaering.de> pysqlite 2.5.2 released ======================= Release focus: minor bugfixes, minor new features. pysqlite is a DB-API 2.0-compliant database interface for SQLite. SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. Go to http://pysqlite.org/ for downloads, online documentation and for reporting bugs. Changes ======= - Like on Connection.rollback(), Connection.commit() now resets all statements associated to the connection, so that the commit() should always succeed (unless other connections create trouble). - pysqlite used to deliver bogus results on cursors that still have unfetched data when a rollback() was done on the connection. A commit() or rollback() now puts the cursor into a "reset" state. If you try to fetch data after commit() or rollback() you will now get an InterfaceError exception instead of bogus data. - For better DB-API compliance, operations on closed cursors now raise exceptions. - Add amalgamation directory to include path when building statically against amalgamation files. Otherwise, building against the amalgamation only worked if you already had the SQLite3 header files in the search path. Like on my development system ;-) - Made sure HAVE_LOAD_EXTENSION is not defined twice. Also made sure that it's OFF if the OMIT macro is defined. - Fixed check if non-UTF8 strings are acceptable input. The check was wrong for OptimizedUnicode. Also added the missing tests for this feature. - Wrap routine sqlite3_load_extension as method load_extension of the Connection object. Compatibility ============= The fact that commit() and rollback() now reset all associated cursors changes the behaviour of pysqlite. Some code that previously worked will now raise InterfaceError exceptions. OTOH the code did not really *work*, because it produced wrong results. In previous pysqlite versions: >>> from pysqlite2 import dbapi2 as sqlite3 >>> con = sqlite3.connect(":memory:") >>> con.executescript("create table t(c); insert into t(c) values (1); insert into t(c) values (2); insert into t(c) values (3);") >>> cur = con.cursor() >>> cur.execute("insert into t values (4)") >>> cur.execute("select * from t") >>> con.rollback () >>> print cur.fetchall () [(1,), (1,), (2,), (3,)] ^ ^ !! Notice the duplicate rows with values (1,) !! This code produced wrong results. With this release, the last cur.fetchall() will raise an exception: >>> print cur.fetchall () Traceback (most recent call last): File "", line 1, in pysqlite2.dbapi2.InterfaceError: Cursor needed to be reset because of commit/rollback and can no longer be fetched from. From edzard at volcanomail.com Thu Mar 5 08:13:02 2009 From: edzard at volcanomail.com (Edzard Pasma) Date: Wed, 4 Mar 2009 23:13:02 -0800 Subject: [DB-SIG] [pysqlite] [ANN] pysqlite 2.5.2 Message-ID: <20090304231302.C95E7F80@resin13.mta.everyone.net> Hello, It looks that the issue with fetch across rollback still can occur in the new version. It turned up when I applied the Pysqlite transaction test suite to some dbapi2 version of my own. Below is a minimal script to reproduce it. It has puzzled me what goes wrong and I would like to believe that the old version is still installed. But the printed version is the new one. Also it behavious slightly different, as the same result comes also after commit. In 2.5.1 you would not get that far. The issue is not causing practical problems but it would be nice to have a work-around to get a clean test result. It is great, by the way, that commit and rollback are now dealing equally with open cursors! Edzard Pasma #!/usr/bin/env python import pysqlite2.dbapi2 as sqlite import sys print "VERSION", sqlite.version, sqlite.sqlite_version, sys.version class Connection (sqlite.Connection): def cursor (self): return Cursor (self) class Cursor (sqlite.Cursor): def execute (self, *args): print "EXEC", args sqlite.Cursor.execute (self, *args) con = Connection ('test.db') cur = con.cursor () try: cur.execute ('drop table t2') except sqlite.OperationalError: pass cur.execute ('create table t2 (c)') cur.execute ("insert into t2 values (1)") cur.execute ('select 1 union select 2 union select 3') con.rollback () print cur.fetchall () VERSION 2.5.2 3.6.11 2.6 (trunk:66714:66715M, Oct 1 2008, 18:36:04) [GCC 4.0.1 (Apple Computer, Inc. build 5370)] EXEC ('drop table t2',) EXEC ('create table t2 (c)',) EXEC ('insert into t2 values (1)',) EXEC ('select 1 union select 2 union select 3',) [(1,), (1,), (2,), (3,)] From steve at holdenweb.com Fri Mar 6 00:38:15 2009 From: steve at holdenweb.com (Steve Holden) Date: Thu, 05 Mar 2009 18:38:15 -0500 Subject: [DB-SIG] [pysqlite] [ANN] pysqlite 2.5.2 In-Reply-To: <20090304231302.C95E7F80@resin13.mta.everyone.net> References: <20090304231302.C95E7F80@resin13.mta.everyone.net> Message-ID: Edzard Pasma wrote: > Hello, > > It looks that the issue with fetch across rollback still can occur in the new version. It turned up when I applied the Pysqlite transaction test suite to some dbapi2 version of my own. Below is a minimal script to reproduce it. It has puzzled me what goes wrong and I would like to believe that the old version is still installed. But the printed version is the new one. Also it behavious slightly different, as the same result comes also after commit. In 2.5.1 you would not get that far. The issue is not causing practical problems but it would be nice to have a work-around to get a clean test result. > It is great, by the way, that commit and rollback are now dealing equally with open cursors! > > Edzard Pasma > > #!/usr/bin/env python > import pysqlite2.dbapi2 as sqlite > import sys > print "VERSION", sqlite.version, sqlite.sqlite_version, sys.version > class Connection (sqlite.Connection): > def cursor (self): > return Cursor (self) > class Cursor (sqlite.Cursor): > def execute (self, *args): > print "EXEC", args > sqlite.Cursor.execute (self, *args) > con = Connection ('test.db') > cur = con.cursor () > try: cur.execute ('drop table t2') > except sqlite.OperationalError: pass > cur.execute ('create table t2 (c)') > cur.execute ("insert into t2 values (1)") > cur.execute ('select 1 union select 2 union select 3') > con.rollback () > print cur.fetchall () > > VERSION 2.5.2 3.6.11 2.6 (trunk:66714:66715M, Oct 1 2008, 18:36:04) > [GCC 4.0.1 (Apple Computer, Inc. build 5370)] > EXEC ('drop table t2',) > EXEC ('create table t2 (c)',) > EXEC ('insert into t2 values (1)',) > EXEC ('select 1 union select 2 union select 3',) > [(1,), (1,), (2,), (3,)] Edzard: Is this reported on bugs.python.org? Do you know where the problems lie? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ From info at egenix.com Thu Mar 19 11:05:34 2009 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Thu, 19 Mar 2009 11:05:34 +0100 Subject: [DB-SIG] ANN: eGenix mxODBC Connect 1.0.1 - Python Database Interface Message-ID: <49C218EE.5030908@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com mxODBC Connect Python Database Interface Version 1.0.1 Our new client-server product for connecting Python applications to relational databases - from all major platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Connect-1.0.1-GA.html ________________________________________________________________________ INTRODUCTION The mxODBC Connect Database Interface for Python allows users to easily connect Python applications to all major databases on the market today in a highly portable and convenient way. Unlike our mxODBC Python extension, mxODBC Connect is designed as client-server application, so you no longer need to find production quality ODBC drivers for all the platforms you target with your Python application. Instead you use an easy to install Python client library which connects directly to the mxODBC Connect database server over the network. This makes mxODBC Connect the ideal basis for writing cross-platform database programs and utilities in Python, especially if you run applications that need to communicate with databases such as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix, Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more, that run on Windows or Linux machines. By removing the need to install and configure ODBC drivers on the client side, mxODBC Connect greatly simplifies setup and configuration of database driven client applications, while at the same time making the network communication between client and database server more efficient and more secure. For more information, please see the product page: http://www.egenix.com/products/python/mxODBCConnect/ ________________________________________________________________________ NEWS mxODBC Connect 1.0.1 is a patch-level release of our new mxODBC Connect product. * More Robust We have made the client and server more robust in case of communication failures. Even if the client applications fail to shutdown the server connection before exiting, the server will free up resources used by the client on the server side and rollback transactions as necessary. * More Platform Support With the 1.0.1 release we are also providing much better platform support for the mxODBC Connect Client: we have fixed a problem in 1.0.0 that prevented the installation of the pre-built clients on non-Linux systems. The mxODBC Connect Client can now be installed on most platforms supported by Python, since it is written in a platform independent, portable way. The pre-built archives also make it possible to integrate the clients into build system such as buildout (used in Zope and Plone) or other distutils-based deployment systems. * Ideal for Building Bridges As a result, connecting from e.g. Mac OS X to an SQL Server database has never been easier. You can even keep the data sources you already have configured on your Windows machine and connect to them as if your application were running on the database server itself. ________________________________________________________________________ UPGRADING You are encouraged to upgrade to this latest mxODBC Connect release. When upgrading, please always upgrade both the server and the client installations to the same version - even for patch level releases. Customers who have purchased mxODBC Connect 1.0 licenses can download and upgrade their existing installations without having to purchase new licenses or upgrades. The licenses will continue to work with version 1.0.1. Users of our stand-alone mxODBC product will have to purchase new licenses from our online shop in order to use mxODBC Connect. You can request 30-day evaluation licenses by visiting our web-site or writing to sales at egenix.com, stating your name (or the name of the company) and the number of eval licenses that you need. http://www.egenix.com/products/python/mxODBCConnect/#Evaluation ________________________________________________________________________ DOWNLOADS The download archives as well as instructions for installation and configuration of the product can be found on the product page: http://www.egenix.com/products/python/mxODBCConnect/ Evaluation licenses for the server part are available free of charge: http://www.egenix.com/products/python/mxODBCConnect/#Evaluation The client part of mxODBC Connect is always free of charge. _______________________________________________________________________ SUPPORT Commercial support for this product is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 19 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From adamff at humval.com Sun Mar 29 00:40:59 2009 From: adamff at humval.com (Adam) Date: Sat, 28 Mar 2009 16:40:59 -0700 Subject: [DB-SIG] PEP 249 Message-ID: <49CEB58B.6000604@humval.com> Suggestion: Cursor execute function return self (cursor) to allow for code like: cursor.execute(SQL).fetchall() instead of cursor.execute(SQL) cursor.fetchall()