Re: Plans for 2.8

On Thu, Oct 4, 2018 at 3:18 PM Mike Bayer <mike_mp@zzzcomputing.com> wrote:

> I can't provide any suggestions, as the feature is very reasonable and
> useful.   But I will lament that pep-249 has nothing about this, which
> means from a driver-agnostic point of view, the situation is pretty
> much unchanged.   Here's code I wrote for Openstack to try to apply
> more specificity to database errors, basically a library of regexes:
> https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/exc_filters.py#L55

Uhm, they also have the problem of not working if the message is
localised... :\ With postgres it woud have been more robust to look at
the extension `pgcode` but of course that's not portable either.

Is there anything in common to all the databases which might be
exposed in an uniform way by the drivers? e.g. the pgcode is actually
something more standard than just postgres: "sqlstate" (or, SQLSTATE,
because '70s) is supposed to be a standard.

If you know that many/all the database emit a sqlstate you may suggest
the dbsig to bless an exception attribute - e.g. `Exception.sqlstate`
- to report it. Of course if postgres says "40P01" and IBM DB2 says
"0911N" to report a deadlock, that's way out of what we can control...


> one thing that would be helpful would be if your fine-grained
> exception classes included more context about the failure.  Like
> UndefinedTable would include the table name as an individual
> datamember e.g. exception.table_name, an error about a foreign key
> constraint would include the constraint name e.g.
> exception.constraint_name, things like that.  You can see in my
> oslo.db library above we are also pulling out other elements from the
> error message to provide more context.

We do already: more details about the exception, if made available by
the database, are made available by the exception `diag` attribute:
see <http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.Diagnostics>.


-- Daniele