Development #60658
Utiliser un verrou explicite sur la table du modèle pour safe_get_or_create
0%
Description
Cf. #60535-6
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Fichier 0001-utils-use-an-exclusive-lock-on-model-s-table-in-safe.patch 0001-utils-use-an-exclusive-lock-on-model-s-table-in-safe.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Avec un LOCK .. IN SHARE MODE
ça ne marche pas du tout, j'ai des deadlocks systématiques, donc LOCK .. IN EXCLUSIVE MODE
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Lié à Development #60645: tests: réduire la variable concurrency ajouté
Mis à jour par Paul Marillonnet il y a environ 2 ans
(C’est rouge, un souci de pylint, le MultipleObjectsReturned
est importé mais pas utilisé.)
En se référent à la table des conflits entre les verrous PG on voit que EXCLUSIVE
reste compatible avec les verrous ACCESS SHARE
, utilisés par les requêtes en lecture. Est-ce que c’est suffisant pour garantir l’intégrité des données ? Est-ce qu’il ne faut pas carrément opter pour ACCESS EXCLUSIVE
?
Mis à jour par Pierre Ducroquet il y a environ 2 ans
J'approuve tout en reculant tout de même, je reste convaincu qu'une unicité est implémentable au niveau de la DB (par ex. avoir une colonne unique_identifier construite selon les cas, avec par exemple un "%s:%s" % (ou, email) si on veut l'unicité sur ce OU), mais à court terme, ça va l'effectuer.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Fichier 0001-utils-use-an-exclusive-lock-on-model-s-table-in-safe.patch 0001-utils-use-an-exclusive-lock-on-model-s-table-in-safe.patch ajouté
Correction erreur pylint, pour valider faut mettre le statut "Solution validée" :)
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
Pierre Ducroquet a écrit :
J'approuve tout en reculant tout de même, je reste convaincu qu'une unicité est implémentable au niveau de la DB (par ex. avoir une colonne unique_identifier construite selon les cas, avec par exemple un "%s:%s" % (ou, email) si on veut l'unicité sur ce OU), mais à court terme, ça va l'effectuer.
J'avais envisagé ça aussi, mais ça pose problème avec l'existant ou il peut déjà y avoir des doublons qu'on ne peut pas corriger, le reste des briques ne le supporte pas et ce n'est pas forcément facile à juger lequel garder, si c'est un vrai doublon ou pas (famille, plusieurs personnes, 1 seul email, ça arrive). Un système qui assure l'unicité pour les futurs comptes sans toucher à l'existant c'est le plus simple pour l'instant.
Mis à jour par Paul Marillonnet il y a environ 2 ans
- Statut changé de Solution proposée à Solution validée
Benjamin Dauvergne a écrit :
Correction erreur pylint, pour valider faut mettre le statut "Solution validée" :)
Oui, du pinaillage pour cette histoire de type de verrou, j’avais pas vu la modification du test qui va avec. C’est bon pour moi.
Mis à jour par Benjamin Dauvergne il y a environ 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 20a8b32ee6a027e99f3a0388fa94888206f1a5d8 Author: Benjamin Dauvergne <bdauvergne@entrouvert.com> Date: Fri Jan 14 10:08:47 2022 +0100 utils: use an exclusive lock on model's table in safe_get_or_create (#60658)
Mis à jour par Frédéric Péters il y a environ 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
utils: use an exclusive lock on model's table in safe_get_or_create (#60658)