Re: [Sqlalchemy-tickets] [sqlalchemy] #2915: Different database backend raise different exceptions on not null constraint violations

[sqlalchemy <mi...@zz...>]

#2915: Different database backend raise different exceptions on not null
constraint violations
-----------------------------------+------------------------------------
      Reporter:  guidow            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  engine            |   Severity:  no triage selected yet
    Resolution:  wontfix           |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------

Comment (by zzzeek):

 as it is, the backends know how to detect exactly *one* type of error
 scenario, that of an exception that indicates the database connection is
 no longer connected.  just that alone is a feature we are constantly
 getting new tickets for as new database conditions are discovered.   Look
 at the awkwardness of the MySQL, Postgresql and Oracle backends for
 example:

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/postgresql/psycopg2.py#L460

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/mysql/base.py#L2132

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/oracle/cx_oracle.py#L813

 note that two of those routines are not only database specific, but
 *DBAPI* specific - messages are sent out from various C drivers which
 aren't the same as those sent out from other interpretation layers.
 Multiply that by the number of things that can go wrong and I'm hoping the
 infeasibility of the task is apparent.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2915#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python