On Sep 12, 2008, at 3:48 AM, Diez B. Roggisch wrote:
> > Hi, > > I've got a table with a unique-constraint. And I've got an automatic > transaction management via decorator in place. > > Now it can happen that the violation of that constraint occurs - > then a > ProgrammingError is raised. As the violation is non-fatal, I try to > catch it, and continue. > > The problem is that the session has been invalidated, and my decorator > fails when trying to commit. > > Is there any chance to prevent this invalidation from happening? > Documention didn't indicate a solution. Probably an Extension helps? any errors raised during flush() will result in a rollback(). If you're using 0.5, the Session recovers gracefully from a rollback so you can try again, but you have to perform the entire contents of the transaction again. The bookkeeping which flush() performs does not currently support partial progress, so it cant issue half of its SQL, fail, and then pick up again where it left off when you try again - the session's state is updated after the flush() completes. So the current way to issue a flush(), catch an error, and continue in the same transaction is to use begin_nested() to issue a SAVEPOINT which the flush() will roll back to. In the bigger picture, SQLAlchemy encourages programming practices that don't rely upon exception throws from the database to determine database state, favoring explicit SELECT operations beforehand (typically via Query and lazyload operations) as needed. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
