[sqlalchemy] Re: postgres autocommit

2009-01-10 Thread Michael Bayer
On Jan 9, 2009, at 10:20 PM, Randall Smith wrote: > > After thinking about it some more, I think that the main issue is a > lack > of auto-commit in the DBAPI. Some drivers implement it and some > don't. > Though it's usually a good idea to use transactions, there are some > times for real

[sqlalchemy] Re: postgres autocommit

2009-01-09 Thread Randall Smith
Michael Bayer wrote: > I think with your project specifically, that of reading lots of > information during a reflection process given a single Connection, we > probably want to look into establishing transactional boundaries for > the reflection process, because in that case you do have the

[sqlalchemy] Re: postgres autocommit

2009-01-09 Thread Michael Bayer
On Jan 9, 2009, at 6:05 PM, Randall Smith wrote: > > There are two problems I see with this. > > 1. The session's view of the database is inconsistent, depending on if > and when queries that modify records are used. Every time a commit is > issued the view of the database (in terms of MVCC) ha

[sqlalchemy] Re: postgres autocommit

2009-01-09 Thread Randall Smith
Jon Nelson wrote: > An alternate solution is to use begin rollback for statements that > (aren't supposed to) update data, like (most) select statements. > That's even cheaper than calling commit usually. There is no begin method in the DBAPI. You could call rollback instead of commit, but

[sqlalchemy] Re: postgres autocommit

2009-01-09 Thread Jon Nelson
An alternate solution is to use begin rollback for statements that (aren't supposed to) update data, like (most) select statements. That's even cheaper than calling commit usually. On Fri, Jan 9, 2009 at 5:05 PM, Randall Smith wrote: > > SA, without a transaction in progress will call commi