On Wed, Jun 5, 2019, at 11:47 AM, Chris Withers wrote: > On 05/06/2019 16:41, Mike Bayer wrote: > > > >> Which gives me: > >> > >> $ python sessions_are_weird.py > >> Traceback (most recent call last): > >> File "sessions_are_weird.py", line 40, in <module> > >> assert session.query(Event).count() == 0 > >> AssertionError > >> > >> Whereas after the rollback, I'd expect that count to be zero... > > > > this is not working because of this: > > > > session.close() > > > > # test: > > session.rollback() > > > > > > the session is closed first so rollback() will do nothing. > > Yeah, that was my point: That session.close() appears to be the problem. > It's a normal and required part of the code under test, but it throws > away the SessionTransaction without rolling it back, so by the time the > test does session.rollback(), it's doing it on a new SessionTransaction > and so has no effect and the assertion fails because there event created > is still around... > > Put differently, the web app closes the session at the end of its > request handling, which seems legit, right? > > 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. 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 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. I'm not sure what the combination of "session.rollback()" + "sub_transaction.rollback()" is trying to achieve or what would be happening between the two. > > 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/806b6413-8537-8813-5c32-1238086300dd%40withers.org. > For more options, visit https://groups.google.com/d/optout. > -- 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/485d0429-ea0c-4d18-96a1-d2e03ffb29a1%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
