[TransWarp] Trying out peak.storage

Phillip J. Eby pje at telecommunity.com
Tue Jan 14 16:34:15 EST 2003


At 10:04 PM 1/14/03 +0100, Geert-Jan Van den Bogaerde wrote:
>Running this script gives no errors and the following output:
>
>-------------------------------------------------------------
>new
>Running SQL: INSERT INTO Contact (id, Name,Surname,Email) VALUES
>(15,'John','Smith','john at smith.com')
>---------------------------------------------------------------
>
>which seems correct. However opening a psql console after the script has
>run shows no new rows added to the Contact table, so it seems the
>changes are not getting commited.
>
>What am I missing here? Or is this a bug or simply not yet implemented?
>(I checked out today's CVS, and all unit tests pass)

The problem is that DBConn hasn't joined the transaction; you must tell it 
to do so.

When executing SQL that modifies data, you should use:

self.DBConn(sql, joinTxn=True)

or:

self.DBConn(sql)
self.DBConn.joinTxn()

or:

self.DBConn(sql)
self.DBConn.joinedTxn

Any of these will cause DBConn to join a transaction if it has not already 
done so.  SQL connections don't automatically do this because some 
databases (e.g. Sybase) impose additional locking overhead on read-only 
operations that occur in a transaction.    Thus, if one has a "read-only" 
transaction, it is bad to be forced to have the SQL connection begin a 
transaction.  So PEAK does not require that a database connection be part 
of a transaction unless requested.  The downside is that you must request 
it, at the minimal typing cost of a keyword argument.

Anyway, once your DBConn joins the transaction, then it will tell 
PostgreSQL to commit as part of the same transaction commit that's invoking 
the INSERT operation, but in a later phase of the commit operation.




More information about the PEAK mailing list