Hi Malcolm,
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.
On Aug 23, 10:47 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-08-23 at 08:07 -0700, Matt Boersma wrote:
>
> [...]
>
> > However, I grep'ed the Django source and found two cases where we
> > catch IntegrityError specifically. cx_Oracle probably misbehaves
> > there currently, but I'm not sure how common these code paths are and
> > what errors could result.
>
> > Currently, our docs say we require cx_Oracle version 4.2.1 or later.
> > It's not reasonable to expect Django users--especially ISPs and
> > corporations-- to upgrade to svn trunk and build the driver. We could
> > ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but
> > even so it's a lot to ask everyone to upgrade to a brand-new
> > driver version. On the other hand, we're not talking about a large
> > number of Django/Oracle users currently, but that should change when
> > we have an official 1.0 release.
>
> > Opinions?
>
> I personally don't view this as being controversial. We should make it
> work with the current cx_Oracle releases that are in common use. We've
> done this before (e.g. MySQL releases, special handling based on version
> numbers, etc). Not supporting the active userbase would be dumb.
>
> I'll have a think about what we can do to handle this properly: I would
> definitely like to catch IntegrityError for those databases that support
> it, so that other generic DatabaseError situations are *not* caught and
> are passed onto whatever higher error handlers are in place. A
> backend-specific function for checking the exception type (that is the
> default for almost everybody and special for Oracle) and then reraising
> if it's not what we want is one solution that comes to mind. Something
> like that should be possible.
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
