Discussion :

[Alexdezark]

Bonjour à tous,

Afin de capter toutes les erreurs dans une transaction j'utilise le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$query_rsDescriptif ="SELECT descriptif FROM activites WHERE ID=".$_POST["ID"];
$rsDescriptif=$this->BDD->query($query_rsDescriptif);
$row_rsDescriptif = $rsDescriptif->fetch(PDO::FETCH_ASSOC);
 
$commit = true;
$this->BDD->beginTransaction();
 
$descriptif=addslashes(trim($_POST["descriptif"]));
 
if($descriptif !=""){
$query_inDescript="UPDATE activites_textes SET texte='".$descriptif."' WHERE ID=".$row_rsDescriptif["descriptif"];
if($this->BDD->exec($query_inDescript)===0) $commit=false;
};
 
$query_rsModifActi="UPDATE activites SET ".$set." WHERE ID=".$_POST["ID"];
if($this->BDD->exec($query_rsModifActi)===0) $commit=false;
 
if($commit == true) $this->BDD->commit();
else {
$this->BDD->rollback();
echo '<script>alert("Cette opération n\'a pas pu être validée en raison d\'une erreur interne.\n Merci de ré-essayer.")</script>';
exit(0);
};

Le problème étant que s'il n'y a pas de changement entre le champ "descriptif" déjà dans la base de données et celui envoyé par la page, $commit devient false.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if($this->BDD->exec($query_inDescript)===0) $commit=false;

ce qui fait que la transaction "rollback" et que les autres requetes ne sont bien sûr pas validées.

Est-ce normal qu'un UPDATE sans modifications renvoie 0 au niveau du nombre de lignes modifiées ?

Si oui, donc il faut faire une vérification d'une éventuelle modification avant de lancer une requête UPDATE ?

Merci d'avance pour vos réponses

[ABCIWEB]

Est-ce normal qu'un UPDATE sans modifications renvoie 0 au niveau du nombre de lignes modifiées ?

Ben oui puisqu'il renvoie le nombre de lignes modifiées...
En regardant ce lien http://dev.mysql.com/doc/refman/5.0/fr/update.html je me dis qu'il faudrait peut-être que tu regardes du côté de mysql_info() pour mieux gérer le retour.

[Alexdezark]

Ouais, enfin apparemment ça fonctionne pas avec les connections PDO...

J'ai donc fait autrement en ne construisant la requête qu'avec des données différentes de ce que contient déjà la table.

Si rien ne change la requête est vide et si la requête est vide je ne la lance pas.

Je pense que dans ce cas il faudrait utiliser un try/catch comme je le faisais
dans ce post

mais ça ne leverai pas forcement d'erreur en cas de non-insertion dans la table "activites_textes"...

Pas facile de trouver l'arme absolue...

PS : bien sûr c'est évident qu'un UPDATE sans modifications ce n'est pas un changement, mais dans la mesure ou on demande un UPDATE d'une ligne, on pourrait considérer que remplacer quelque chose par quelque chose d'identique c'est déjà une action...

[RunCodePhp]

Salut

Tel que tu présente les choses dans le 1er post, apparemment que les UPDATE se fassent ou pas (retour d'une ligne ou pas) dans l'une ou l'autre requête ne devrait pas déboucher sur l'annulation de la transaction (donc des 2 UPDATE).
Du coup, vérifier le nombre de lignes affectées ne serait pas nécessaire, pas de rollback dans ce cas là.

Par contre, un try/catch + rollback de même que la transaction se justifiera dans le sens où il faudra à tout prix annuler les 2 UPDATE lors d'un éventuel plantage de l'une ou de l'autre requête.

mais dans la mesure ou on demande un UPDATE d'une ligne, on pourrait considérer que remplacer quelque chose par quelque chose d'identique c'est déjà une action...

On pourrait, mais ce n'est pas le cas.
La doc le précise d'ailleurs : http://dev.mysql.com/doc/refman/5.0/fr/update.html

UPDATE retourne le nombre d'enregistrements ayant changé

Je ne peux pas te dire s'il y a quelque chose qui obligerait à MySQL de retourner 1 pour 1 ligne quand on modifie un contenu par le même.
Si cela t'est imposé, je ne vois pas d'autres solutions que de faire un SELECT pour vérifier si le contenu est le même ou pas.

Une astuce néanmoins pour éviter ou contourner ce problème serait de rajouter une date de mise à jour (genre DATETIME), qui fera qu'il y aura obligatoirement 1 des données (la date) qui sera différente.
Faut voir si ceci est envisageable dans ton cas.

[ABCIWEB]

if($this->BDD->exec($query_inDescript)===0) n'est vrai que dans deux conditions.
1/ Soit le nouveau contenu est identique à l'ancien et mysql ne fait rien.
2/ Soit la condition WHERE ID=".$row_rsDescriptif["descriptif"] n'est pas remplie.


Pour différencier les deux tu peux toujours faire un simple SELECT COUNT(*) FROM activites_textes WHERE ID = ".$row_rsDescriptif["descriptif"]." avant de faire les updates suivants (si j'ai bien compris ton problème).

Les transactions peuvent éviter des problèmes techniques mais ne peuvent pas pour autant garantir l'intégrité des données si les pb viennent d'ailleurs... Il faut donc soit faire des contrôles supplémentaires soit utiliser des astuces comme mentionné par RunCodePhp. Je vois pas d'autres solutions.

Sinon juste une remarque en survolant ton premier post, pour optimiser de nombreux updates ce serait le moment d'utiliser des requêtes préparées.