Discussion :

[JohnLocke]

Bonjour,
mon trigger est le suivant, j'aimerais pouvoir update la date de dernière modification d'un topic lorsque quelqu'un y participe (et ajoute donc une entrée dans la table Message), pour le moment mon trigger ressemble à ca:

Code :

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

1
2
3
4
CREATE TRIGGER mod_date AFTER INSERT
ON message FOR EACH ROW
UPDATE topic SET topic.last_update = CURRENT_TIMESTAMP where topic.idtopic = message.concern
END;

dans phpMyAdmin je règle le délimiteur sur ";"

mais j'obtient l'erreur:
#1064 - Erreur de syntaxe près de 'END' à la ligne 4

si quelqu'un sait pourquoi j'obtient cette erreur, merci.

[Sebwar]

il n'y a pas de END sans BEGIN et vu que vous n'avez qu'une seule instruction vous n'avez pas besoin de BEGIN.......END
donc enlevez le END et ca devrait passer

https://dev.mysql.com/doc/refman/5.5...er-syntax.html

[isabelle.letrong]

Bonjour JohnLocke,

Petite(s) remarque(s) importante(s) :
1. Cela aurait été un plus d'avoir le DDL des tables 'topic' et 'message', en leur absence, on ne peut savoir si votre code a du sens.
2. ceci étant, dans le code suivant du trigger AFTER portant sur la table 'message'

Code :

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

UPDATE topic SET topic.last_update = CURRENT_TIMESTAMP where topic.idtopic = message.concern

vous faites référence à la colonne 'concern' de la table 'message' de manière incorrecte : message.concern doit etre remplacé par new.concern !)

[escartefigue]

C'est peut être dommage de faire un trigger uniquement pour moucharder l'horodatage d'insertion avec la current date !
Si les insertions sont centralisées dans un service unique, c'est même contre-productif
Une valeur par défaut dans le DDL de création la table est une solution possible et moins couteuse si le type de colonne est compatible

[isabelle.letrong]

C'est peut être dommage de faire un trigger uniquement pour moucharder l'horodatage d'insertion avec la current date !
Si les insertions sont centralisées dans un service unique, c'est même contre-productif

La notion de service centralisé unique est une question intéressante.
Personnellement, je milite haut et fort pour que ces services dits 'centralisés' ne soient pas des services clients développés avec un code tiers (PHP, JAVA, 'Hibernatisés') mais bels et bien intégrés aux serveurs MySQL sous la forme de routines stockées (procédures/fonctions/triggers) qui font force de lois. Les modes en matière de langage de développement évoluent mais au final les données, SQL et le modèle relationnel restent. Si on excepte les interfaces utilisateurs, on peut TOUT faire avec ces routines, et particulièrement tout ce qui concerne le développement de la gestion du cœur de business d'une entreprise.

Laissons donc les framework gérer les interfaces utilisateurs et le moteur relationnel les données, leur pérennité et leur intégrité ...