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);")
<pysqlite2.dbapi2.Cursor object at 0xb7e79d40>
>>> cur = con.cursor()
>>> cur.execute("insert into t values (4)")
<pysqlite2.dbapi2.Cursor object at 0xb7e79770>
>>> cur.execute("select * from t")
<pysqlite2.dbapi2.Cursor object at 0xb7e79770>
>>> 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 "<stdin>", line 1, in <module>
  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: <gopnp9$27l$1@ger.gmane.org>

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