DB API 2.0 and transactions

[flyingfred0]

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 at alumni.cs.utexas.edu> schrieb im
> Newsbeitrag news:mailman.92.1118167102.10512.python-list at python.org...
> | 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 butt 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
> 
> 
> |
> 
> 
>