2008/9/22 Fabien Jakimowicz <[EMAIL PROTECTED]>: > 2008/9/22 Renaud (Nel) Morvan <[EMAIL PROTECTED]>: >> >> >>> > Est tout à fait possible, le seul moyen fiable de garantir l'unicité >>> > c'est de gérer la contrainte au niveau de la base de donnée. >>> >>> Es-tu sur que cela se produit avec l'utilisation que rails fait des >>> transactions SQL ? >>> >> >> Tu as raison de douter, mais il n'y a rien de plus simple à >> vérifier :) >> >> 1) Myisam ne supporte pas les transaction, donc à moins d'utiliser les >> hooks mysql (procédure, intégrité, ON DUPLICATE ...) ou de locker la >> table tu n'as pas de garantie que 2 requetes distinctes soient >> executées de facon atomiques >> 2) Innodb supporte les transactions mais ne garantie absoluement pas >> le coté atomique de plusieurs transaction distinces exemple: >> >> Si on prend l'exemple d'une table innodb users avec un champ email >> >> client mysql1: >> $ mysql -u root database >> mysql> START TRANSACTION; >> Query OK, 0 rows affected (0,00 sec) >> mysql> select * from users where email='[EMAIL PROTECTED]'; >> Empty set (0,00 sec) >> mysql> INSERT INTO users set email= '[EMAIL PROTECTED]'; >> Query OK, 1 row affected (0,08 sec) >> select * from users where email='[EMAIL PROTECTED]'; >> +--------------------+ >> | email | >> +--------------------+ >> | [EMAIL PROTECTED] | >> +--------------------+ >> 1 row in set (0,00 sec) >> >> client mysql2: >> mysql> START TRANSACTION; >> Query OK, 0 rows affected (0,00 sec) >> mysql> select * from users where email='[EMAIL PROTECTED]'; >> Empty set (0,00 sec) >> mysql> INSERT INTO users set email= '[EMAIL PROTECTED]'; >> Query OK, 1 row affected (0,08 sec) >> select * from users where email='[EMAIL PROTECTED]'; >> +--------------------+ >> | email | >> +--------------------+ >> | [EMAIL PROTECTED] | >> +--------------------+ >> COMMIT; >> Query OK, 0 rows affected (0,00 sec) >> >> client mysql1: >> COMMIT; >> Query OK, 0 rows affected (0,00 sec) >> select * from users where email='[EMAIL PROTECTED]'; >> +--------------------+ >> | email | >> +--------------------+ >> | [EMAIL PROTECTED] | >> +--------------------+ >> | [EMAIL PROTECTED] | >> +--------------------+ >> 2 rows in set (0,00 sec) >> >> Boom :) ... >> Les transactions ici empire le problème car allonge le temps où la >> base de donnée ne possède pas le users avec l'email toto alors que >> pourtant il va être committé >> >> Ce n'est pas un problème de RAILS c'est juste une impossibilité de >> gérer coté soft des contraintes niveau DB, ceci dit c'est "good enough >> la plupart du temps" sauf si tu as des requêtes qui prennent des >> plombes à commiter. >> > > autant pour moi, j'ai pris l'habitude de ne bosser qu'avec postgres > qui n'a pas du tout ce comportement et qui justement passe > correctement ce test. > > Sauf si j'ai mal effectué le test ;)
En effet, j'ai mal fait le test et théoriquement toute base sql aura ce comportement. -- http://fabien.jakimowicz.com --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
