Closed sqlalchemy-bot closed 16 years ago
Michael Bayer (zzzeek) wrote:
Michael Bayer (zzzeek) wrote:
The only "bug" i can see here is that, surprisingly, sessionmaker defaults transactional
to True
whereas Session
defaults it to False
. I'm a little surprised its like that....and unfortunately is pretty tough to fix until version 0.5.
However, as far as the actual behavior of transactional=True, its not a bug. when you're in transactional=True, there's always a transaction in progress. Saying begin() inside of a transaction, whether its a transaction on a Connection
, Engine
, or Session
, has the effect of "nesting" the begin call such that a stack is incremented, and is decremented whenever commit()
is called. so if you were to call begin()
twice in a row, you'd call commit()
twice as well and the second commit()
would close the "outermost" pair of begin/commits and actually issue the COMMIT. Its the same with transactional=True; everytime you call commit()
, begin()
is called immediately afterwards (which results in the actual BEGIN as soon as a connection is re-grabbed from the pool).
So the solution to your issue is just to not call begin()
; being in transactional=True means that BEGIN will be issued as soon as the connection is grabbed from the pool. If, OTOH, you are genuinely looking for a transaction that is local to itself and is isolated from the ongoing session-level transaction, you have the option to either use a different session, or to use a "nested" transaction via begin_nested()
. begin_nested()
is currently only supported on Mysql, Postgres, and Oracle, as it makes usage of SAVEPOINT.
jek is suggesting right now we change the whole terminology to autocommit=False/True
. That might be a better way to make this clearer.
Changes by Michael Bayer (zzzeek): removed "0.5.0" milestone
Changes by Michael Bayer (zzzeek): set state to "resolved"
Changes by Michael Bayer (zzzeek): set milestone to "0.5.0"
Issue created by Anonymous
This is with MySQL using SA 0.4.2p3
I'm creating my engine like this:
and my session like this:
and using it like this (in another module):
Usually I just do this:
and always followed by sess.close()
However, in case I update(object) a bunch of objects. I wrap that loop like this:
With the logging turned up (and verified by manual inspection of the DB), the "BEGIN" statement and "UPDATE" statements occur, but no "COMMIT" (or "ROLLBACK" for that matter....)
I have to use a slightly different session construction, specifying
transactional=False
tosessionmaker
explicitly. Then I get what I expect. This seems like a bug.