On May 12, 2011, at 6:42 PM, Luper Rouch wrote: > 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...
yeah am just curious what a little application that actually does something would seem like, SQLA isn't tailored towards event driven programming. I couldn't do much to make it adaptable to such unless I had in mind how one writes such an app. The main thing is that logical operations are expected to be in transactions. When everything is asynchronous, its not clear to me what such an application considers to be a "transaction". this applies to folks doing stuff like twisted also (some of whom use SQLA also, haven't needed new hooks). > > 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). You should never have to enclose *ALL* of anything in any kind of block - you should have a standard block or construct that deals with the scope of usage of a single Session / transaction. If you don't have that then your architecture needs to change in order to allow it. -- 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.
