Version imprimable
8OCitation:
enfin au changement de certaines versions l'obligation de les droper avant puis de les recréer sous peine d'avoir de sales surprises!
Encore un bug ?
Manque de tests de non-régression ?
Tu peux préciser ? Quel genre de "sales surprises" ?
Un petit conseil à alitazichibi tout de même
Réservez vos actions de mise à jour ou d'insert dans un trigger UNIQUEMENT sur un AFTER INSERT ou AFTER UPDATE et réservez vos triggers BEFORE INSERT et BEFORE UPDATE UNIQUEMENT pour vos contrôles d'assertion avant tout COMMIT sur vos TRANSACTIONS dans la mesure du possible. Ca vous évitera bien des soucis et des heures de débogage inutiles...
Je pense qu'eric à fait allusion à un souci qui m'est déjà arrivé à savoir, qu'après un upgrade de version faisant intervenir un upgrade dans les tables de définition de triggers, que l'upgrade se fasse mal et que le trigger devienne inopérant (génération d'erreur à l'exécution). Obligation de le supprimer et de le recréer pour que le trigger soit redéfini proprement dans la base...Citation:
Tu peux préciser ? Quel genre de "sales surprises" ?
c'est pas un bug là encore c'est documenté... je peux te les citer si tu veux... 5.0.10, 5.0.16, 5.1.0 ou 5.5.0
si tu passes d'une version antérieure à l'une d'elles tu dois le faire sous peine de ne plus pouvoir droper tes triggers (sauf à droper la table)
en gros c'est à chaque version ou des changement majeur sont faits dans mysql ou la gestion des triggers...
y a bien des chose dans mon cours sur le procédural cinephil, lis le à défaut de le corriger :ccool::mouarf:
sinon oui il vaut mieux bien comprendre l'utilisation de after ou before vu que le trigger est vu comme faisant partie la transaction