On Aug 25, 10:51 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > I just noticed that the MySQL backend also fails on this get_or_create > test. It is returning an OperationalError instead of an IntegrityError. > Looks like MySQL returns errno 1364 (ER_NO_DEFAULT_FOR_FIELD) in this case > but this is not recognized as anything special in MySQLdb so it's just > mapped to a general OperationalError. I don't see a corresponding place in > the mysql backend to do the sort of catch & transform you have found to do > with Oracle?
OperationalError according to PEP 249 is for "errors that are related to the database's operation and not necessarily under the control of the programmer, e.g. an unexpected disconnect occurs, the data source name is not found, a transaction could not be processed, a memory allocation error occurred during processing, etc." That doesn't seem to fit an INSERT lacking a NOT NULL value (and no table default value). So at first glance, I'd say that's a bug in MySQLdb that should be rectified so it also raises IntegrityError. And following what I just committed in [8545], we should perhaps find a way to work around the driver so we can rely on IntegrityError in this situation. But since the MySQL backend isn't as customized as Oracle, there's no existing place to trap this. We could add execute() and executemany() to a new MySQLCursor class to fix it similarly, but as Senator Obama likes to say, "that's above my pay grade." > Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
