Project

General

Profile

Development #60658

Utiliser un verrou explicite sur la table du modèle pour safe_get_or_create

Added by Benjamin Dauvergne 13 days ago. Updated 7 days ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
14 Jan 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Cf. #60535-6


Files


Related issues

Related to Authentic 2 - Development #60645: tests: réduire la variable concurrencyRejeté13 Jan 2022

Actions

Associated revisions

Revision 20a8b32e (diff)
Added by Benjamin Dauvergne 13 days ago

utils: use an exclusive lock on model's table in safe_get_or_create (#60658)

History

#1

Updated by Benjamin Dauvergne 13 days ago

Avec un LOCK .. IN SHARE MODE ça ne marche pas du tout, j'ai des deadlocks systématiques, donc LOCK .. IN EXCLUSIVE MODE

#2

Updated by Benjamin Dauvergne 13 days ago

#3

Updated by Paul Marillonnet 13 days ago

(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 ?

#4

Updated by Pierre Ducroquet 13 days ago

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.

#5

Updated by Benjamin Dauvergne 13 days ago

Correction erreur pylint, pour valider faut mettre le statut "Solution validée" :)

#6

Updated by Benjamin Dauvergne 13 days ago

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.

#7

Updated by Paul Marillonnet 12 days ago

  • Status changed from Solution proposée to 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.

#8

Updated by Benjamin Dauvergne 12 days ago

  • Status changed from Solution validée to 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)
#9

Updated by Frédéric Péters 7 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF