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
-~----------~----~----~----~------~----~------~--~---
