public inbox for [email protected]  

help / color / mirror / Atom feed

From: Daniele Varrazzo <[email protected]>
To: Michael Bayer <[email protected]>
Cc: [email protected]
Subject: Re: Plans for 2.8
Date: Thu, 4 Oct 2018 15:47:17 +0100
Message-ID: <CA+mi_8b0jZdp4oaLkB+KEO4-T=BiUpQuQedJ4GGw-vY6mDiz-w@mail.gmail.com> (raw)
In-Reply-To: <CA+RjkXFUxez3gwKj0UniV2p89H6_bL4UOG5=TUxOH=Bky83w3w@mail.gmail.com>
References: <CA+mi_8auWr+u4DwLGnu3JOu=jhMAV_8OPnMtMuXOr+0iMN5LgA@mail.gmail.com>
	<CA+RjkXFUxez3gwKj0UniV2p89H6_bL4UOG5=TUxOH=Bky83w3w@mail.gmail.com>

On Thu, Oct 4, 2018 at 3:18 PM Mike Bayer <[email protected]> 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

view thread (8+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Plans for 2.8
  In-Reply-To: <CA+mi_8b0jZdp4oaLkB+KEO4-T=BiUpQuQedJ4GGw-vY6mDiz-w@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox