Thank you, I looked at it and it is quite more complicated than I thought it was, really extensive what you have there. If it's not too much to ask can anyone explain a little bit how to use that?
On 4/27/15, Mike Bayer <mike...@zzzcomputing.com> wrote: > > > On 4/27/15 7:40 AM, David Allouche wrote: >>> On 18 Apr 2015, at 02:20, dcgh...@gmail.com wrote: >>> >>> Hi everyone, I have a considerably amount of code that uses SQLAlchemy >>> and I want to implement a decorator that captures the SQLAlchemy >>> exceptions, then make session.rollback() and recall the decorated >>> function, so I don't have to write the try except statement whenever I >>> use SQLAlchemy. >>> For implementing such a decorator I need the exceptions I can certainly >>> capture to make session.rollback() and the app keep working fine because >>> there are exceptions that will cause an endless loop and should never be >>> captured (e.g., generating the same primary key due to a bug and always >>> raising IntegrityError) >>> So, can anyone tell me what are those exceptions that are safe to make >>> session.rollback()? >> I guess that your intent is to retry transactions that failed because of a >> serialisation error in the SERIALIZABLE isolation level. >> >> My understanding is that, to SQLAlchemy, this is a database-specific >> issue. You can expect the SQLAlchemy exception to be an OperationalError, >> but you would need to add additional checks to specifically identify the >> kind error returned by your database driver. An argument could be made >> that serialisation errors should be wrapped in a more specific exception >> class by SQLAlchemy, but I do not believe that is the case at the moment. >> >> I am no expert, so please someone correct me if I am wrong. > > that's pretty much the current situation - OperationalError refers to > "something went wrong with the connection" and IntegrityError means > "something went wrong with the data the query is attempting to modify". > > In Openstack we have an elaborate system of catching those exceptions we > care about across many backends; this is probably more than you need but > this is sort of what is needed: > https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/exc_filters.py > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/Uifgo8n7yHw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
