Re: DB API 2.0 and transactions

I've found it's occasionally necessary to go one lever deeper and use the _pg module directly so you are in control of your transactions (instead of letting pgdb automatically put you in one).

vincent wehren wrote: 
"Christopher J. Bottaro" <cjbottaro@xxxxxxxxxxxxxxxxxxxx> schrieb im
Newsbeitrag news:mailman.92.1118167102.10512.python-list@xxxxxxxxxxxxx
| Hi,
| Why is there no support for explicit transactions in the DB API?  I mean
| like transaction() to start the trans and commit() and rollback() would
end
| the trans or something.
|
| The reason why I ask is because I wrote a daemon that interacts with a
| Postgres DB.  The value of CURRENT_TIMESTAMP according to Postgres is NOT
| the actual walltime, but the walltime when the current transaction
started.
|
| This gets weird when using the Python DB API to interact with Postgres
| because a transaction gets started in 3 places:  connection, commit,
| rollback.
|
| So consider the daemon:
|
| [pseudo code]
| connect # begin trans at 12:00
| sleep waiting # lets say 15 mins
| wake up
| put entry in db using CURRENT_TIMESTAMP # oops
| [/code]
|
| Oops, the CURRENT_TIMESTAMP evaluates to 12:00, not 12:15.
|
| Now I know there are ways around this...
| 1)  In Postgres, you can get the walltime and cast it to a timestamp.
| 2)  In Python, you can just do an empty commit in order to "manually"
start
| a new transaction.
|
| I just think its a bit weird because this bit me in the *** for quite a
| while and this didn't happen when doing the same thing in other langs.
|
| Anyone have any opinions on this?

The described behavior seems to be totally in synch with expectations

(both in accordance with PostgreSQL docs and the DB-API.)

These "other languages" *must* be doing something wrong! ;)

( Auto-commit set to "on" perhaps? )



Regards,

-

Vincent Wehren


|



.