On May 12, 4:17 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On May 12, 2011, at 7:25 AM, Luper Rouch wrote: > > >> I still have the exact same issue when using SessionExtension's > >> before_flush() and after_flush_postexec() methods, demonstrated here > >> :http://paste.pocoo.org/show/387444/ > > >> Line 87 raises the same "InvalidRequestError: The transaction is > >> inactive due to a rollback in a subtransaction. Issue rollback() to > >> cancel the transaction." error. > > > Someone on IRC suggested to do the rollback twice in > > handle_exceptions(). This seems to work and solve the issue. > > right, you're using begin(subtransactions=True). That will allow you to > have an "inner" "transaction" block, but won't save you from the fundamental > nature of the Session, in that it expects a rollback/commit for every > transaction block (or a close() cancels everything). > > The reason "subtransactions=True" is required, is literally just a, "by > setting this flag you agree that you really want to be doing this". Its a > flag that is really not needed for the vast majority of use cases. > > In your test, the rationale for the @handle_exceptions decorator is not > really clear. The Session's maintream mode of usage is, just use it, then > call rollback() or commit() at the end - the "nesting" capability is to allow > code that runs unconditionally in a transaction, regardless of whether or not > the Session is in "autocommit" mode. If you don't plan on ever dealing with > a Session in "autocommit" mode, the nesting of the transaction block doesn't > really have much use. after_flush_postexec() in particular is already > within the flush() processes' internal transaction block. > > Feel free to come up with a brief description of what you're really trying to > do from a usage standpoint - i.e. not what part of Session you want to jiggle > with but how the program would actually make use of what's going on. > Throughout these messages, that remains unclear, and more detail would make > the rationale/use case you're proposing apparent.
I use SA events to dispatch events with louie [1]. Signals are then connected to all kind of things, e.g. maintain history of operations on a table, update a cache, etc... That's why I need some kind of generic failure recovery mechanism (the @handle_exceptions decorator), when a flush is done it may trigger many operations, which may raise exceptions and leave SA in this "broken" state until a rollback is issued (and I don't want to enclose ALL the flush() in try/except blocks). [1] http://pypi.python.org/pypi/Louie/1.1 -- 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.
