On Mon, Aug 25, 2008 at 12:12 PM, Malcolm Tredinnick < [EMAIL PROTECTED]> wrote:
> On Mon, 2008-08-25 at 08:47 -0700, Matt Boersma wrote: > > I can wrap the execute() and executemany() calls in oracle\base.py in > > a try/except that re-raises this specific error as an IntegrityError: > > > > try: > > return Database.Cursor.execute(self, query, > > self._param_generator(params)) > > except DatabaseError, e: > > # cx_Oracle <= 4.4.0 wrongly raises a DatabaseError for > > ORA-01400. > > if e.message.code == 1400 and type(e) != IntegrityError: > > e = IntegrityError(e) > > raise e > > > > This seems to work fine, fixes the get_or_create test case, and > > doesn't require changes outside the oracle backend. Let me know if > > you think that's acceptable. > > I hadn't thought of that, but it looks like the best solution by far. > Everybody can then write natural-looking code that catches > IntegrityError without having to remember to call some custom Django > function to work around a problem they probably don't even know exists. > > 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? 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 -~----------~----~----~----~------~----~------~--~---
