IntegrityError not handled properly

Simon Chabot simon.chabot at logilab.fr
Wed Feb 12 09:39:08 CET 2020


Hi Noé

Quoting Noé Gaumont (2020-02-11 18:11:25)
> Actual behavior (with python2 and CW 3.26.14):

I did not try with python2

> Actual behavior (with python3 and CW 3.26.14 or 3.27):

With python3, I got, as you said a psycopg2.errors.UniqueViolation.
Using sqlite driver leads to the expected behavior.

With postgresql, in my webbrowser I can read the following message:

« ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique «
key_acea95cac9de1e6fa4ab7b08c190d0d6 » DETAIL: La clé « (cw_name)=(test) »
existe déjà. »

And, reading the source code in `cubicweb/server/sources/natives.py` and
especially theses lines [0], makes me believe that a UniqueTogetherError used to
be raised, as you are expecting.

With SQLite, the message is « UNIQUE constraint failed:
cw_Denomination.cw_name », and matches the condition line 739, which raises a
UniqueTogetherError.

In the Postgresql message, we have the columns name only, and not the table
name. It seems that a CWUniqueTogetherConstraint entity, with a name matching
`unique_[a-z0-9]{32}` is expected in the message, but there is not (we have
`key_SOMETHING`. Nor there is a message matching `cstr[a-f0-9]{32}` to raise the
ViolatedConstraint

In your snippet, if you change the schema as follow:

class Denomination(EntityType):
    __unique_together__ = [('name', )]
    name = String(maxsize=256)


You obtain the expected behavior.
As you say, it's worth more investigating to understand / handle the differences
between both cases. My guess is that `__unique_together__` generates an index,
for instance in my table I have :

Index :
    "unique_7a9fcd372b067965cd7ca4632f2e9785" UNIQUE, btree (cw_name)

and the related CWUniqueTogetherConstraint entity with the same name.

But, when the `unique=True` keyword is used, we have an index whose name is
`key_SOMETHING` and no related CWUniqueTogetherConstraint.

Index :
    "key_acea95cac9de1e6fa4ab7b08c190d0d6" UNIQUE CONSTRAINT, btree (cw_name)


I hope that helps to understand the issue,

[0] : https://hg.logilab.org/review/cubicweb/file/3.27.1/cubicweb/server/sources/native.py#l723

--
Simon Chabot
logilab.fr - services en informatique scientifique et gestion de connaissances



More information about the cubicweb-devel mailing list