Database exceptions problem in multi-db setups

[Waldemar Kornewald]

There are no common DatabaseException and IntegrityError classes since multi-db got committed. Django uses the default backend's exceptions. The problem is that every backend defines its own exception classes, so you can't catch an error raised by a secondary backend.

[Russell Keith-Magee]

In fairness, this isn't a multi-db problem - there has *never* been a common base class for DatabaseException or IntegrityError classes. multi-db means that you can trigger this problem in a single project; previously, you would have had to share a reusable app between two different databases.

[Waldemar Kornewald]

Hmm, I don't understand what you want to say. Previously I would've just imported django.db.IntegrityError, for example. That's OK in a single-db setup (even with a reusable app), but not in a multi-db setup with the current backend code.

[Russell Keith-Magee]

My point is that *none* of the backends raise django.db.IntegrityError - they raise psycopg.IntegrityError or cx_Oracle.IntegrityError or MySQLdb.IntegrityError. There isn't a base class to any of these exceptions, so there isn't any common behavior that you can rely on in the general case.

However, this problem has become slightly more pointed now that we have multiple databases. As you pointe out, django.db.DatabaseException points to the DatabaseException for the default database, which isn't especially helpful if you're in a multiple database vendor situation. We need to do something about this for 1.2 - I'm just not sure what. Suggestions welcome.

[Russell Keith-Magee]

First pass at unifying exceptions under multi-db

[Russell Keith-Magee]

(In [12352]) Fixed #12702 -- Introduced a common implementation of DatabaseError and IntegrityError, so that database backends can (re)raise common error classes. Thanks for Waldemar Kornewald for the report.

[Jacob]

Milestone 1.2 deleted