Karen - I agree - this was very strange - that's why I was confused. I've not yet upgraded to 0.96.1, so I guess that's the next step.
Thanks, Bob On Jan 18, 1:01 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > On Jan 18, 2008 10:51 AM, Robert Swerdlow <[EMAIL PROTECTED]> wrote: > > > > > I posted this note at comp.lang.python and the response there was that > > this all works outside of Django. What is the problem with using MySQL > > OperationalErrors with Django? > > > --------- > > In our database code (we are using django v0.96) we wanted to catch > > and handle MySQL OperationalErrors. We use both the Django models and > > database connections. > > > However, even though we confirmed that a > > _mysql_exceptions.OperationalError are raised (particularly 1213 > > deadlock), we cannot catch them with try/except. > > > Here's the code that did not work: > > > import _mysql_exceptions > > from _mysql_exceptions import OperationalError > > > try: > > database_code() > > except (_mysql_exceptions.OperationalError, OperationalError), e: > > error_handling() > > > Originally, we just had one import, but tried both to ensure that was > > not the problem. In debugging, we confirmed that both type(e) and > > e.__class_ were <class _mysql_exceptions.OperationalError>. > > > The only work-around we found was: > > > try: > > database_code() > > except Exception, e: > > if e.__class__.__name__.find('OperationalError') != -1: > > error_handling() > > else: > > raise > > > This seems silly. If we used any other exception, the except clause > > seems to work correctly. > > > Is there a problem with _mysql_exceptions.OperationalError? Is there > > a better work-around? > > ----------- > > I cannot recreate any problem with catching OperationalErrors using Django > 0.96.1. To test I added a field to a model definition that doesn't exist in > the database and tried a get -- this generates an OperationalError, which I > was able to catch: > > Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. > (InteractiveConsole)>>> from mini.models import Authors > >>> import _mysql_exceptions > >>> def tryget(): > > ... try: > ... a = Authors.objects.get(pk=22) > ... except _mysql_exceptions.OperationalError, e: > ... print 'get failed with OperationalError: ' + str(e) > ... return > ... print 'get succeeded, a = ' + str(a) > ...>>> tryget() > > get failed with OperationalError: (1054, "Unknown column 'mini_authors.Xtra' > in 'field list'")>>> import django > >>> django.VERSION > > (0, 96.099999999999994, None) > > > > My MySQLdb is version 1.2.2. > > I don't know why a 1213 OperationalError would be treated any differently > than the 1054 one above. > > It sounds very odd to me that you verified the class of the exception you > catch with 'catch Exception, e' is <class > _mysql_exceptions.OperationalError> but you cannot 'catch > _mysql_exceptions.OperationalError'. > Sorry, but I have no explanation for how that could happen....all I can say > is catching OperationalErrors when running Django code works for me. > > Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---