In tracking down some bugs in my application I have come accross two issues
with SQLObject's transaction support.
The first issue is that transactions don't work as documented.
conn =3D DBConnection.PostgresConnection('yada')
trans =3D conn.transaction()
# These calls cause a new connection to be created with autoCommit=3DTr=
p =3D Person.get(1, trans)
p.firstName =3D 'Bob'
# This commits conn, a connection object that hasn't been used
# This call also uses the second connection object, not conn, and
p.firstName =3D 'Billy'
# This rolls back conn, a connection object that hasn't been used
The effect here is that nothing gets rolled back. I am aware that calls
such as Person.get(), Person.set() and the SQLObject constructor take a
'connection' keyword argument, which can force the use of conn, but that
doesn't seem like the right way of doing it.
The second issue is that autoCommit gets turned off on a (psycopg)
connection when the Transaction object is created. When the transaction is
rolled back, the connection is released back into the pool. Now the pool
contains some connections with autoCommit=3DTrue (the default) and one with
autoCommit=3DFalse. This is bad if your code assumes that autoCommit=3DTru=
(which mine does, as does Ian's example code). The result is that any
updates that happen to be made by that connection are never committed.
I haven't been able to find any discussion on this list about these issues.
Let me know if any of you have experienced them and if I should attempt to
fix them and submit a patch.
--- I'd give my right arm to be ambidextrous. ---