On 12 juil, 23:37, Michael Bayer <mike...@zzzcomputing.com> wrote: > > the session always does things in a transaction , as does any DBAPI > connection running in the default mode of operation as according to > spec. Whether or not the Session leaves the transaction open after > an individual execute() or flush() operation is dependent on the > "autocommit" setting, which defaults to False - meaning the Session > remains open within a transaction as soon as its used, which remains > until either rollback(), commit(), or close() is called. After any > flush() which fails, session.rollback() must be called. the > subtransaction is specifically the internal begin/rollback() pair > issued by the failed flush() call. Start reading > fromhttp://www.sqlalchemy.org/docs/05/session.html#flushing > on downwards to get more detail about how this works.
Ok, thanks. Then I want to ask: why the complication? It looks like a weird and difficult to grasp behaviour. Why doesn't a failed flush() leave the session in a consistent state (either rolled back or not, but not something in-between)? By the way, I solved my problem by doing the UPDATE with an ORM-less query, so that I can catch the failure without rolling back the transaction. Perhaps flush() should have an optional flag to avoid rolling back on errors? This would help the cases where potential errors are expected, and the developer knows how to correct them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
