Removing `__unique_together__` doesn't remove corresponding index in postgresql.
Après le retrait d'une contrainte __unique_together__
, et la mise à jour de l'instance via sync_schema_props_perms
, il à été remarqué qu'une contrainte était encore présente dans la base de données sous la forme d'un index sur la table.
Après analyse, avant la migration, deux indexes d'unicité étaient présents sur la table en question. L’exécution du sync_schéma_props_perms
permet bien le retrait d'un des indexes, mais le second n'était pas accessible via CubicWeb.
Le bug entre en jeu lors du renommage d'une entité qui contient déjà une contrainte d'unicité. Après renommage, la nouvelle entité possède deux indexes d'unicité distincts dans PostgreSQL.
Pour vérifier dans PostgreSQL :
- Renommer une entité qui possède une contrainte d'unicité (ex nouveau nom 'EntityX')
- Se connecter à sa base de donnée avec psql
psql -p <port> <db-name> -U <username>
- Examiner la table en question
\d cw_entityx
Il devrait y avoir plusieurs lignes formatées comme ceci :
Indexes:
"cw_coolproductionsitepumpgroup_pkey" PRIMARY KEY, btree (cw_eid)
"unique_4af906c571fea10f6ae4c23518f77ec1" UNIQUE, btree (cw_name, cw_pump_group_of)
"unique_f792ba1dcedfe50071cdb76d7125105d" UNIQUE, btree (cw_name, cw_pump_group_of)
"idx_5c108a671e5c1d70fb306ab6dcbedb5f" btree (cw_use_power_contract)
"idx_850955cd1e84d4308accd69e347c2059" btree (cw_pump_group_of)
Où on peut voir qu'on a plusieurs indexes d'unicité.
Un dump de la base de donnée (PostgreSQL 12) en question peut être mis à disposition (Je peux mettre ça où ?)
Elle doit être restaurée sur v0.20210607.0.