Recent changes to feature-requests

pyodbc support

Ray Van Dolson — Tue, 08 Jul 2008 00:30:48 -0000

Per this:

http://www.sqlobject.org/SQLObject.html#ms-sql-server

Only adodbapi and pymssql are supported for accessing MSSQL.

Would it be feasible to add in support for pyodbc?

SQLObject should determine joinColumn from Class Name

Till Maas — Sun, 03 Feb 2008 17:59:36 -0000

Currently SQLObject determines the joinColumn for MultipleJoin from the name of the table.

In the documentation it is recommended to use "user_table" as a table for an class called User. When one now creates another class, e.g. Address that has a ForeignKey from User in a column called "user", one needs to add joinColumn='user_id' to the MultipleJoin definition within the User class, otherwise one only gets a totally strange python traceback, when one tries to access u.addresses.

I attached a simple example, that makes it more clear, where the problem here is.

I use python-sqlobject-0.9.2-1.fc7 from Fedora.

Update DB schema from Class description

Tim Kientzle — Sat, 03 Mar 2007 22:43:43 -0000

According to the documentation, SO can update a
class with information about new columns in the database:

"SQLObject can read the table description from the database, and fill in the class columns"

However, I would prefer to update my SO class descriptions and have new DB columns created automatically. I can manually addCol to create new columns if I know what they are, but I would like for SO to query the DB, identify columns missing from the DB and automatically create them. (Dropping and recreating the entire table is clearly out of the question.)

This would cover 90% of my requirements for managing schema evolution.

Bug in the release of a transaction connection

Hong Yuan — Tue, 06 Dec 2005 09:49:48 -0000

In one of my application using SQLObject, I found that
once I have
used a transaction, the next insert with an auto
sequence will fail.

Debugging the code, I suspect this could be a bug in
the Transaction
class. The following is what happens:

1. A transaction object is created. The corresponding
physical
database connection is set to autommit=0 by
self._dbConnection._setAutoCommit(self._connection, 0) in
Transaction.__init__.

2. The processing with the transaction is finished.
Transaction object
is deleted. The physical database connection is
returned to the pool
using self._dbConnection.releaseConnection in the method
_makeObsolete. However, the connection still has
autommit=0.

3. A new SQLObject is to be created. The
_SO_finishCreate method calls
_queryInsertID to inert the data. _queryInsertID gets a
physical
connection from the pool, which happens to be the one
just returned by
the transaction, i.e. with autocommit=0. This means the
INSERT SQL
will not automatically commit. The transaction is still
in progress
when _SO_finishCreate returns.

4. _init(id) is called. It calls _SO_selectOne to see
if the data with
the given ID is actually inserted into the database.
However,
_SO_selectOne gets another physical database connection
from the pool,
and can therefore not see the new data just inserted.
It raises
SQLObjectNotFound.

The problem is during transaction creatiion, the
autocommit status of
the physical database connection has been changed. But when
transaction object is deleted, the original status is
not restored.

I made the following patch to dbconnection.py and my
problem is gone.

Can anyone check my diagnosis and the fix?

Index: dbconnection.py

===================================================================

--- dbconnection.py (revision 1334)

+++ dbconnection.py (working copy)

@@ -857,6 +857,8 @@

def _makeObsolete(self):
self._obsolete = True
+ if self._dbConnection.autoCommit:
+
self._dbConnection._setAutoCommit(self._connection, 1)

self._dbConnection.releaseConnection(self._connection,
explicit=True)
self._connection = None

Parametrized queries

Oleg Broytman — Mon, 22 Nov 2004 12:07:40 -0000

Ian, why use sqlStringReplace and _[lL]ikeQuoted? Why
not import and use quoting/escaping functions from
low-level DB API modules? At least where they are
avalable at all...

Why not import DB API exceptions from those modules and
reexport them as SQLObject exceptions?

Binding transactions to Zope transactions

Anonymous — Sat, 04 Oct 2003 14:57:17 -0000

Support to bind transactions to Zope transactions, so
that transactions automatically get created/commited
when a Zope transaction is created/commited.

The Modeling framework (modeling.sf.net) already has
support for this. (see the
ZModeling/ZEditingContextSessioning/__init__.py code).

(Debian unstable switched to python 2.2 as default for
Zope some time ago - so it's now possible to use
SQLObject and Zope 2.x together :)