Partie 3 · Automatismes

Triggers

Le cas demande d'identifier les événements de base qui justifient un traitement automatique au niveau SQL. Quatre questions guident la réflexion :

Quels contrôles doivent avoir lieu avant une écriture ?
Quelles traces doivent être écrites après certaines opérations ?
Dans quels cas un trigger peut-il préparer une notification (par exemple pour une opportunité critique) ?
Quels risques ou limites garder à l'esprit avec ce mécanisme ?

Les critères d'évaluation regardent la pertinence et la maîtrise : utilité réelle (logs, automatisation), absence d'effets de bord, bonne granularité BEFORE/AFTER.

Moment	Usage typique dans le cas
`BEFORE` écriture	contrôler/refuser (budget négatif, champ obligatoire)
`AFTER` écriture	journaliser (log métier), historiser, préparer une notification

À toi de coder

Un trigger AFTER INSERT qui journalise

Traçabilité : les opérations importantes doivent laisser une trace. Un trigger AFTER INSERT écrit dans log_metier après chaque nouvelle annonce, sans que l'application ait à y penser. Dans le corps du trigger, la nouvelle ligne s'appelle NEW.

Complète le trigger pour qu'il enregistre l'action 'INSERT' et l'identifiant de l'annonce insérée.

import sqlite3
con = sqlite3.connect(":memory:", isolation_level=None)
con.executescript("""
CREATE TABLE marche(id INTEGER PRIMARY KEY, titre TEXT);
CREATE TABLE log_metier(id INTEGER PRIMARY KEY, action TEXT, marche_id INTEGER);
CREATE TRIGGER trg_log_insert ___ INSERT ON marche
BEGIN
  INSERT INTO log_metier(action, marche_id) VALUES ('INSERT', ___.id);
END;
""")
con.execute("INSERT INTO marche(titre) VALUES ('Classes modulaires')")
con.execute("INSERT INTO marche(titre) VALUES ('Base vie')")
rows = con.execute("SELECT action, marche_id FROM log_metier ORDER BY id").fetchall()

Ctrl/⌘+Entrée

À toi de coder

Un trigger BEFORE INSERT qui refuse une donnée invalide

Quels contrôles doivent avoir lieu avant une écriture ? Ici : un budget estimatif négatif n'a pas de sens. Un trigger BEFORE INSERT peut interrompre l'opération avec RAISE(ABORT, 'message') (syntaxe SQLite : exemple adapté).

Complète le trigger. L'insertion invalide doit lever une erreur (capturée dans erreur) et la ligne valide doit être conservée.

import sqlite3
con = sqlite3.connect(":memory:", isolation_level=None)
con.executescript("""
CREATE TABLE marche(id INTEGER PRIMARY KEY, titre TEXT, budget REAL);
CREATE TRIGGER trg_budget ___ INSERT ON marche
WHEN NEW.budget < 0
BEGIN
  SELECT RAISE(___, 'budget négatif');
END;
""")
erreur = None
try:
    con.execute("INSERT INTO marche(titre, budget) VALUES ('Mauvais', -5)")
except sqlite3.DatabaseError as e:
    erreur = str(e)
con.execute("INSERT INTO marche(titre, budget) VALUES ('Bon', 1000)")
nb = con.execute("SELECT COUNT(*) FROM marche").fetchone()[0]

Ctrl/⌘+Entrée

Risques et limites (hors cours, notions générales)

Un trigger s'exécute sans être appelé : il peut surprendre. Un trigger qui en déclenche un autre crée des enchaînements difficiles à lire ; un traitement lourd dans un trigger ralentit chaque écriture ; une erreur dans un trigger fait échouer l'écriture qui l'a déclenché. D'où le critère « absence d'effets de bord » : un trigger doit rester petit, prévisible et documenté. Préparer une notification (écrire une ligne dans une table de notifications) est plus sûr que d'envoyer un e-mail directement depuis le trigger.

Vérifie que tu as compris

Pour refuser une annonce avec un budget négatif, il faut un trigger…