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 less
> common use case of an explicit Connection object that's in autocommit
> mode. That's something we can look into in 0.6.
>
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 auto-commit.
For example, I'm working on a thick client query tool in which a
connection might be held open for days. There is an auto-commit mode as
well as a transaction mode. In auto-commit mode, changes in the
database from any session should be visible immediately.
The issue is really just when using SA as a high level DBAPI. Because
transactions require explicit calls (e.g. trans = conn.begin()), I think
that most people would imply that no transaction is in effect without
this explicit call and would be surprised to discover there is one.
Maybe you didn't intend for it to be used like I'm using it, but I must
say that for the most part, it does a great job of creating a standard
interface for the various drivers. Also, I like ResultProxy,
reflecttable and other goodies.
Curious. Why would you choose not to use the driver's autocommit
functionality if available? For example, with psycopg2, you could do:
con.set_isolation_level(0)
--Randall
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
