Je pense que pour être vraiment sur du résultat, tu devrais utiliser
des contraintes sur ta base de données directement.
http://api.rubyonrails.org/classes/ActiveRecord/Locking/Pessimistic.html
Car là, avec une transaction, 2 utilisateurs peuvent passer si leur
validation se fait en même temps (la 1ère requête de la transaction
passe et la seconde n'a aucune contrainte pour ne pas passer)
--
Posted via http://www.ruby-forum.com/.
C'est un cas qui peut se produire bien plus souvent qu'on ne le pense
: il suffit d'avoir la malchance de 2 utilisateurs qui font au même
moment (proche de la milliseconde) la même action ...
Quitte à faire un lock, une contrainte sur la base/table est encore
plus sage : cela ne bloque pas la base de données comme un lock et ca
laisse la base gérer la fiabilité des données.
renchap
en effet, mais les index uniques (qui sont implémentés dans rails)
contredisent totalement cette logique rails.
De plus, tout n'est pas possible depuis les modèles ;)
C'est un choix qui se comprend si l'on souhaite réellement ne pas
dépendre de la base de donnée choisie. Mais celà ne doit pas non plus
empêcher toute optimisation dans le cas d'un projet où le choix de la
base est connu et pérenne
C'est un cas qui peut se produire bien plus souvent qu'on ne le pense
: il suffit d'avoir la malchance de 2 utilisateurs qui font au même
moment (proche de la milliseconde) la même action ...
C'est pas exactement le même problème. La transaction permet d'enchainer
plusieurs requêtes en annulant tout si l'une d'entre elles échoue.
Le lock interdit l'accès en écriture à une table (ou juste une ligne de
cette table) tant qu'on a pas rendu la main.
C'est pas exactement le même problème. La transaction permet d'enchainer
plusieurs requêtes en annulant tout si l'une d'entre elles échoue.
Le lock interdit l'accès en écriture à une table (ou juste une ligne de
cette table) tant qu'on a pas rendu la main.