On Jan 31, 2014, at 9:27 AM, Wolfgang Schnerring <[email protected]> wrote:
> Hello list, > > pardon the innocent/dumb question: wouldn't it make sense to expire_all() > on begin_nested() and rollback()? > > My concrete example goes like this: > > savepoint = session.begin_nested() > session.delete(stuff) > session.begin_nested() > # Now, if I don't call session.expire_all() here, stuff won't be perceived > as gone > perform_checks_while_pretending_that_stuff_is_gone() > savepoint.rollback() > # And if I don't call session.expire_all() here, stuff won't be perceived > back the rollback of a savepoint expires all of those objects which were modified within the scope of the savepoint. I’m not sure what an expiration at the beginning of begin_nested() would accomplish (other than forcing everything to re-load), though a flush() is emitted at that stage, so that if and when a rollback() does happen we can safely expire back knowing that all state has been flushed. In older versions of SQLAlchemy, the rollback() did expire everything like that of an outer transaction, however this is unnecessary and interferes with performance for the case where short-run savepoints are invoked against a small number of objects within a larger transaction, so the feature was improved to only expire those objects which might have changed since the savepoint. this feature is well tested. if you are observing that it isn’t working, produce a fully reproducing and self-contained test case and post a ticket, thanks.
signature.asc
Description: Message signed with OpenPGP using GPGMail
