Trigger et procédure stockée pour annuler une suppression ?

bonjour,
j'ai vu que MySQL pouvait faire des triggers et des procédures stockées.
Je cherche à faire en sorte (dites-moi si c'est faisable ou pas) que quand une requete DELETE est effectuée, alors cette dernière est annulée et remplacer par une requête de type :

Code:

---

UPDATE matable SET champ_visibilite=false, champ_date_suppression=current_timestamp() where ID=xxxx ;

---

Ainsi, chaque ligne supprimée, sera en fait masquée pour l'utilisateur mais jamais réellement supprimée en base de données.
Sachant que chaque table a des champs champ_visibilite et champ_date_suppression, je reproduirais le même schéma sur chacune.

est-ce possible, ça doit être un classique comme utilisation du trigger, non ?
Si vous avez un très bon tutotriel sur le trigger MySQL et/ou les prco stockées, ce serait gentil de les communiquer.

Bonne journée

Bonsoir,

Les triggers "instead of" ne sont pas encore implémentés dans MySQL.

Une solution est de passer par un trigger after classique et d'alimenter une table "corbeille" qui contienne les lignes supprimées.
Pour voir toutes les lignes, dont les supprimées, il faudra créer un vue UNION des 2 tables.

Pour le coup c'est même mieux car avec un trigger instead of delete sur une table comment faire des purges ?
mauvaise réponse : "désactiver le trigger, supprimer et réactiver le trigger" car pendant cette opération les autres suppressions ne seront pas loguées
meilleure réponse : "prévoir dans le trigger une exception, par exemple sur le login, pour pouvoir faire la purge"

merci je vais tenter une solution.

j'argumente ta mauvaise solution :

Citation:

---

mauvaise réponse : "désactiver le trigger, supprimer et réactiver le trigger" car pendant cette opération les autres suppressions ne seront pas loguées

---

problème impossible avec une option "site en maintenance" assurant que toi seul est connecté.

Si vous voulez vous prémunir des DELETE, vous pouvez en tout cas n'accorder aucun droit en DELETE aux utilisateurs hors admin

Salut clavier12AZQSWX.

Votre raisonnement est mauvais !
Quand vous demandez la suppression d'une ligne, MySql va vous proposer de le faire. Pourquoi en serait-il autrement ?

Si vous ne désirez pas de suppressions physiques, mais des suppressions logiques, n'utilisez pas la requête "delete" mais plutôt une procédure stockées.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

-------------- START TRANSACTION --------------   -------------- DROP DATABASE IF EXISTS `base` --------------   -------------- CREATE DATABASE IF NOT EXISTS `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci` --------------   -------------- drop table if exists `test` --------------   -------------- CREATE TABLE IF NOT EXISTS `test` ( `id` integer unsigned NOT NULL AUTO_INCREMENT primary key, `message` varchar(255) NOT NULL, `suppress` char(01) NOT NULL default 'N' ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED --------------   -------------- INSERT INTO `test` (`message`) VALUES ('un'),('deux'),('trois'),('quatre'),('cinq') --------------   -------------- select * from `test` --------------   +----+---------+----------+ | id | message | suppress | +----+---------+----------+ | 1 | un | N | | 2 | deux | N | | 3 | trois | N | | 4 | quatre | N | | 5 | cinq | N | +----+---------+----------+ -------------- delete from `test` where id = 4 --------------   -------------- select * from `test` --------------   +----+---------+----------+ | id | message | suppress | +----+---------+----------+ | 1 | un | N | | 2 | deux | N | | 3 | trois | N | | 5 | cinq | N | +----+---------+----------+ -------------- commit --------------   -------------- DROP PROCEDURE IF EXISTS suppress --------------   -------------- CREATE PROCEDURE `suppress` (IN In_id integer) DETERMINISTIC NO SQL BEGIN UPDATE `test` SET suppress='Y' WHERE id=IN_id; END --------------   -------------- call suppress(2) --------------   -------------- select * from `test` --------------   +----+---------+----------+ | id | message | suppress | +----+---------+----------+ | 1 | un | N | | 2 | deux | Y | | 3 | trois | N | | 5 | cinq | N | +----+---------+----------+ -------------- COMMIT --------------   Appuyez sur une touche pour continuer...

---

Comme on peut le voir dans cet exemple, la ligne a supprimer a été marqué à 'Y'.

@+

Citation:

---

Envoyé par Artemus24

Salut clavier12AZQSWX.

Votre raisonnement est mauvais !
Quand vous demandez la suppression d'une ligne, MySql va vous proposer de le faire. Pourquoi en serait-il autrement ?

Si vous ne désirez pas de suppressions physiques, mais des suppressions logiques, n'utilisez pas la requête "delete" mais plutôt une procédure stockées.

---

L'IHM rudimentaire côté user (je ne peux pas donner le nom) ne me permet pas de mettre un bouton lançant la procédure stockée ni même une autre requête SQL, juste une instruction de delete. C'est pour cela que la partie suppression logique ne peut être faite que au niveau mysql dans mon cas.
bien sûr si ça n'avait tenu qu'à moi j'aurai mis un bouton vers un code php qui execute un update directement voire mieux un insert dans une table copycat "poubelle" comme suggérée plus haut.

merci Artemus pour votre proposition de code, elle est très instructive.

bonne journée

Salut clavier12AZQSWX.

Votre point de départ est la requête de suppression "delete from ..." et rien d'autre.
Dans ce cas, il est indispensable de passer par un déclencheur. On ne peut pas faire autrement.
Sauf qu'en l'état, MySql interdit les astuces pour contourner l'interdiction de modifier la lignes que vous désirez supprimer physiquement.
Mais on peut interdire la suppression physique de cette même ligne, en utilisant "signal".

J'ai pensé à plusieurs solutions, comme appeler une procédure stockée, faire des requête dynamique, ou encore encapsuler la requête.
Rien n'y fait, cela ne fonctionne pas.

Comme le dit Michel.Priori, les triggers "instead of" ne sont pas implémentés dans MySQL, et c'est dommage.

@+

Bonjour,

Il est possible de mettre en place un tel mécanisme d'inhibition d'une mise à jour ou d'un delete, suivi d'un traitement complémentaire.
Il faut procéder de la manière suivante :

• Le code applicatif doit être en procédure stockée (malheureusement trop peu pratiqué),
• On se met en mode transactionnel,
• Le prologue de la procédure stockée commence par un 'savepoint'
• Le contrôle du delete se fait via un trigger qui inhibe le delete en lançant une exception
• Dans son handler d'exception, la procédure stockée délinquante qui aurait invoqué à tort le delete commence par un rollback to savepoint suivi de l'appel d'une procédure stockée qui traite spécifiquement cette exception et fait éventuellement les mises à jour demandées, voire logue l’événement.

Cela suppose donc de mettre en place une architecture de développement appropriée (adieu le php qui invoque directement le sql....)

merci pour cette proposition et le temps passé à la rédiger....
mais j'ai effectué une autre méthode "plus simple" .
-dans la table j'ai ajouté un champs "visbilité" oui/non tinyint default à 1
-dans l'ihm, j'ai appelé ce même champ "à supprimer" (1=non, 0=oui) derriere les radio button
-l'ihm remplie l'écran avec une filtre "visibilité=1"
les salariés sont formés, maintenant s'ils veulent supprimer qqchose, ils doivent l'indiquer explicitement en tournant ce flag.

ensuite à un autre endroit, je rapporte (pour un cadre) tout ce que les salariés ont demandé à supprimer. et ce cadre lui, a un vrai bouton supprimer.

Juste une remarque.
Vous avez effectivement trouvé une réponse applicative mais le contrôle se fait uniquement dans une application et une seule.
Les routines stockées permettent de maîtriser ces contrôles directement au niveau du SGBDR, donc de se protéger de toute mise à jour demandée par un client quelconque...

Mais vous pouvez parfaitement estimer que cela est acceptable dans votre contexte