Trigger

Un trigger è una regola che vive dentro il database e scatta da sola ogni volta che una riga di una tabella viene inserita, modificata o eliminata. Non dipende da chi ha scritto: che la scrittura arrivi da una schermata, da un'API, da uno script o da un'altra applicazione collegata allo stesso database, il trigger gira.

È questo l'argomento a favore dei trigger, ed è anche l'attenzione che richiedono — logica che gira senza che nessuno la chiami è logica che nessuno vede accadere.

#Dove vivono i trigger

Nell'albero del datasource, dentro il gruppo Programmazione, accanto alle Funzioni / Procedure:

Cliccare su un trigger lo apre in una scheda dello spazio di lavoro, con il suo flusso disegnato.

#Creare un trigger

1. Passa il mouse sul datasource e apri il menu ⋯.
2. Scegli Nuovo trigger. Si apre la finestra con i dati iniziali del trigger — il flusso si costruisce dopo nel canvas.
3. Compila:

Campo	Che cos'è
Nome	Il nome del trigger nel database. La convenzione suggerita è trg_mia_tabella.
Tabella	La tabella sorvegliata.
Momento	BEFORE (prima che la riga sia scritta) o AFTER (dopo).
Eventi	INSERT, UPDATE, DELETE — almeno uno. Alcuni motori accettano più eventi nello stesso trigger, altri uno solo.

4. Conferma con Crea e apri il canvas.

Il trigger nasce come bozza: esiste già nella piattaforma, ma non è ancora stato applicato al database. Finché è una bozza, l'albero lo identifica come tale.

#Momento ed eventi, nella pratica

Scelta	Per che cosa
BEFORE INSERT/UPDATE	Normalizzare o completare i valori prima che vengano salvati — mettere un codice in maiuscolo, riempire un campo derivato.
AFTER INSERT/UPDATE/DELETE	Reagire a ciò che è già accaduto — scrivere uno storico, aggiornare un totale in un'altra tabella.

I valori della riga sono disponibili a seconda dell'evento: i Valori nuovi (NEW) esistono nell'INSERT e nell'UPDATE; i Valori vecchi (OLD) appaiono solo quando il trigger ascolta UPDATE o DELETE — in un INSERT non c'è una riga vecchia da mostrare.

#Il canvas del trigger

Il flusso si disegna in un canvas, e il suggerimento in alto riassume il gesto: trascina funzioni/procedure dall'albero sul canvas; il doppio clic su una casella configura i suoi output/input.

Nella barra sopra il canvas ci sono, da sinistra a destra:

Pulsante	Che cosa fa
Impostazioni	Riapre nome, tabella, Momento ed Eventi del trigger.
(il riepilogo)	Il nome, la tabella, il momento e gli eventi, sempre in vista.
Espressione	Aggiunge un nodo di espressione al flusso.
Visualizza SQL	Mostra il trigger compilato, senza eseguire nulla.
Salva e applica al DB	Salva e applica il trigger al motore.

#La casella della tabella — che cosa entra nel flusso

La prima casella del canvas è la tabella: è da lì che escono i valori della riga che ha fatto scattare il trigger. Facci doppio clic per aprire gli Output del trigger e scegliere cosa questo trigger espone al flusso: singole colonne, l'intera riga (JSON), o entrambi.

• Valori nuovi (NEW) — la riga come resta.
• Valori vecchi (OLD) — la riga com'era.
• In entrambi i casi, oltre alle singole colonne, puoi esporre l'intera riga (JSON) — utile per consegnare tutto in una volta a una funzione di storico.

Ogni uscita scelta diventa una porta nella casella, pronta a essere collegata.

#Le funzioni e le procedure

Il lavoro, in un trigger, è fatto da funzioni e procedure che esistono già nel database. Trascinale dall'albero (Programmazione ▸ Funzioni / Procedure) sul canvas: ognuna diventa una casella con un parametro per ingresso.

1. Collega una porta della tabella al parametro che alimenta — il parametro comincia a mostrarsi come connesso.
2. Un parametro senza collegamento resta con il suo valore predefinito.
3. Anche le funzioni restituiscono un valore: la porta di ritorno può alimentare un'altra casella, concatenando i passaggi.
4. Il menu della casella stessa ha Rimuovi dal flusso.

Per disfare un collegamento, clicca sulla linea: Rimuovere questa connessione? Il parametro smette di ricevere questo valore.

#I nodi di espressione

Fra una porta e un parametro non sempre il valore va bene così com'è. Il pulsante Espressione aggiunge un nodo che affina/trasforma i valori: dichiari gli Input (con + input), ci colleghi le porte, e scrivi l'Espressione SQL usando {a}, {b}… per gli input collegati — per esempio upper({a}) || '-' || {b}. Il risultato esce dalla porta del nodo e va dove vuoi.

Fai doppio clic sul nodo per configurarlo (la casella stessa dice doppio clic per modificare… mentre è vuota).

#Vedere l'SQL prima di applicare

Visualizza SQL apre l'anteprima — SQL del trigger (anteprima) — con l'avviso che conta: Compilato con le tue modifiche attuali — non è stato eseguito nulla. Valuta e applica quando vuoi.

È il passaggio di sicurezza: vedi esattamente che cosa verrà creato nel database, puoi copiarlo, mostrarlo a chi amministra il motore, e solo dopo applicarlo. La stessa finestra ha il pulsante Salva e applica al DB a portata di mano.

#Applicare il trigger

Salva e applica al DB fa entrambe le cose: salva il disegno e crea il trigger nel motore. Quando va a buon fine, la piattaforma conferma: Trigger applicato al database.

Prima di applicare, il disegno viene verificato. I rifiuti sono espliciti:

Messaggio	Che cosa manca
Dai un nome al trigger (Impostazioni).	Il nome.
Scegli la tabella (Impostazioni).	La tabella sorvegliata.
Scegli almeno un evento (Impostazioni).	Almeno uno fra INSERT/UPDATE/DELETE.
Il canvas non ha nessuna funzione/procedura.	Un flusso vuoto non fa nulla — trascina almeno una funzione.
C'è un nodo di espressione senza espressione definita.	Un nodo di espressione in bianco.

#Eliminare un trigger

Il menu ⋯ del trigger nell'albero ha Elimina, con conferma — Eliminare il trigger "…"? — ed è definitivo: il trigger esce dal database.

#Vedere che cosa c'è nel database

La Console SQL, sotto il diagramma del modello, è il posto per verificare l' effetto di un trigger: scrivi una query, Esegui, e guarda le righe reali. È anche da qui che si ispeziona ciò che c'era già prima che tu arrivassi.

#Trigger, script o workflow?

Le tre cose automatizzano, e la scelta giusta evita mesi di confusione:

Strumento	Gira…	Buono per
Trigger	Dentro il database, a ogni scrittura della tabella.	Regole che devono valere per tutte le scritture: storico, campi derivati, totali.
Script	Fuori dal database, a mano, pianificato o come passaggio di un'API.	Lavoro pesante, integrazioni, file, invii — tutto ciò che dura o che parla con l'esterno.
Workflow	Come un processo con passaggi, decisioni e attività umane.	Approvazioni, circuiti con persone in mezzo, attese.

#Perché no…?

• Perché non appare Nuovo trigger nel menu del datasource? Il motore collegato non supporta i trigger disegnati nel canvas. Puoi comunque crearli in SQL, e appaiono nell'albero come trigger esterni.
• Perché il trigger continua a dire che è una bozza? È stato creato ma non è ancora stato applicato. Aprilo e usa Salva e applica al DB.
• Perché non vedo i Valori vecchi (OLD)? Il trigger non ascolta UPDATE né DELETE. In un INSERT non esiste una riga vecchia.
• Perché non riesco a collegare una porta a un parametro? Non tutti i collegamenti hanno senso — verifica di collegare un'uscita (a destra della casella) a un ingresso (a sinistra dell'altra).
• Perché il trigger non fa nulla? Un flusso senza funzioni non genera nessun lavoro: la compilazione lo rifiuta. E verifica il Momento — un BEFORE e un AFTER non vedono la stessa cosa.
• Perché le scritture sono diventate lente dopo aver creato il trigger? Il trigger gira su ogni riga scritta. Se chiama lavoro pesante, quel lavoro ha cominciato ad accadere a ogni inserimento — in quei casi, il posto è uno script pianificato.