On 05/06/2019 17:15, Mike Bayer wrote:
How come close() doesn't rollback the SessionTransaction if it throws it
away?
that's currently what .close() does, it discards the connection. this
is safe because the connection pool ensures transactions are rolled
back. This might have to change with some of the 2.0 things I'm
thinking about but it's not clear yet.
Anyway, you don't get a rollback here because the session is bound to an
external connection so the connection pool is not involved.
Ah, right, so under normal conditions, if I just close a session, any
transaction and subtransactions in flight will be rolled back when the
connection is returned to the pool?
if you
want to roll back the work that the application did, that would be your
sub_transaction.rollback():
sub_transaction = conn.begin_nested()
try:
session = Session()
# code under test:
event = Event(text='some stuff got done')
session.add(event)
session.flush()
session.close()
finally:
sub_transaction.rollback()
assert session.query(Event).count() == 0
Sure, but the test then fails when the code is correct:
try:
Base.metadata.create_all(bind=conn, checkfirst=False)
Session.configure(bind=conn)
sub_transaction = conn.begin_nested()
try:
session = Session()
# code under test:
event = Event(text='some stuff got done')
session.add(event)
session.flush()
session.commit()
session.close()
# test:
sub_transaction.rollback()
assert session.query(Event).count() == 1
finally:
sub_transaction.rollback()
finally:
transaction.rollback()
The panacea I'm after is to be able to run the DDL in a transaction, run
each test in a subtransaction off that which is rolled back at the end
of each test, but also be able to check that the code under test is
doing session.commit() where it should. Where the pattern we're
discussing, I certainly have the first two, but as you can see from what
I've just pasted above, the third one isn't there, but is it possible?
the test harness is giving you two choices. you can look at the state
of the DB after your program has done some things and *before* your
harness has reversed its work, or you can look at the state of the DB
*after* your harness has reversed its work.
Unless I'm missing something, neither of these let the test confirm that
the code under test has called commit() when it should.
cheers,
Chris
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/d7f7c9ac-2d32-6e60-efac-f86b501683f7%40withers.org.
For more options, visit https://groups.google.com/d/optout.
