In MySQL, gli strumenti che abbiamo a disposizione per automatizzare operazioni e processi sono essenzialmente di due tipi: i trigger e gli eventi. I trigger, come già detto in precedenza, sono dei particolari meccanismi che vengono associati alle tabelle e che vengono attivati nel momento in cui una determinata condizione si verifica. Gli eventi, invece, seppur concettualmente simili ai trigger, possono essere configurati per essere eseguiti un numero arbitrario di volte e in uno specifico momento della giornata, senza che nessuna condizione sia responsabile del loro avvio. Un'ulteriore differenza tra trigger ed eventi consiste nel fatto che, mentre i trigger sono adoperati per manutenere o aggiornare i dati delle tabelle, gli eventi sono generalmente usati per manutenere o aggiornare i dati o la struttura dell'intero database.
Cos'è un evento
Essendo gli eventi programmabili in particolari momenti della giornata, questi possono essere considerati a tutti gli effetti come dei cron job. Gli eventi possono infatti essere registrati presso uno scheduler, chiamato appunto event scheduler, che si occuperà di mandarli in esecuzione periodicamente e automaticamente.
L'event scheduler di MySQL non è nient'altro che un particolare thread del DBMS, che viene eseguito in background dal sistema e che si preoccupa a eseguire gli eventi che vi sono stati registrati.
L’assonanza tra il crontab di Unix o il Task Scheduler di Windows, con l'Event Scheduler MySQL è evidente e corretta. Concettualizzando l'argomento, gli eventi che abbiamo sopra definito non sono altro che particolari "trigger temporali", ovvero trigger che vengono attivati in maniera programmata, piuttosto che in presenza di specifiche alterazioni di dati o strutture. Questo è il motivo principale per cui si predilige l'uso della parola "evento" piuttosto che "trigger".
La presenta degli eventi, e di uno scheduler che si occupa della loro gestione, permette grande libertà di azione. Un caso di studio classico che viene spesso presentato quando si parla dell'event scheduler potrebbe essere il seguente.
Supponiamo di avere un database che si occupa di memorizzare i post che i vari utenti hanno pubblicato su un blog nel corso del tempo. Se un amministratore non si occupasse periodicamente di cancellare i post troppo vecchi, si rischierebbe ben presto di saturare la sua memoria. Cancellare manualmente (ovviamente tramite delle query SQL) i post del database ormai datati, è un'operazione che dovrebbe essere automatizzata per assicurare l'integrità del nostro database. Per far ciò, si potrebbe creare un evento, registrarlo nell'event scheduler e configurarlo per farlo eseguire in un particolare periodo temporale. L'amministratore del database in questo modo non dovrebbe più occuparsi direttamente del problema della cancellazione dei post troppo datati.
Proprietà di un evento
Un evento MySQL è un particolare task o processo, che viene eseguito programmaticamente e che possiede le seguenti proprietà:
- Un evento MySQL è univocamente identificato da un nome dallo schema al quale è assegnato
- Un evento esegue una specifica azione che viene specificata tra il blocco
BEGIN
…END
della sintassi di MySQL - Un evento può essere eseguito a intervalli regolari una o più volte. Può avere una data di inizio, una data di fine o entrambe
- Se un evento non viene terminato possono rimanere istanze pendenti che si possono accumulare nel corso del tempo
- Gli eventi vengono definiti tramite la sintassi SQL che conosciamo
Registrazione di un evento
Per far sì che un evento venga eseguito dal DBMS, è necessario che venga registrato nell'event scheduler di MySQL. Sarà questo infatti ad occuparsi di eseguire periodicamente (nel tempo definito dall’amministratore) i vari eventi. Prima di creare un evento, bisogna che l’event scheduler venga attivato all’interno del nostro database, perché di default questo è disabilitato. Per far ciò bisogna lanciare il seguente comando SQL nella console di MySQL:
SET GLOBAL event_scheduler = ON;
Dopo aver abilitato lo scheduler possiamo verificare quali eventi sono registrati al suo interno. Eseguiamo il comando:
SHOW PROCESSLIST;
Per disabilitare nuovamente l’event scheduler, possiamo eseguire il comando seguente:
SET GLOBAL event_scheduler = OFF;
Abilitato lo scheduler, possiamo dare vita a un evento. Crearne uno è un'operazione molto simile a quella adoperata quando viene creato un trigger o una stored procedure, ovviamente con opportune differenze.
Lo scheletro SQL per la creazione di un evento è il seguente:
CREATE EVENT [IF NOT EXIST] event_name
ON SCHEDULE periodo_di_esecuzione
DO
corpo_dell_evento
Nella prima parte del codice SQL presentato, vediamo che un evento deve possedere un nome univoco prima di poter essere creato. La clausola ON SCHEDULE
, invece, definisce il periodo in cui l'evento deve essere eseguito. Abbiamo due possibili configurazioni temporali per un evento:
ON SCHEDULE AT [...]
ON SCHEDULE EVERY number-of-time-units time-unit [STARTS timestamp] [ENDS timestamp]
La sintassi AT
permette l’esecuzione dell’evento una singola volta, mentre EVERY
permette di definire sia il numero di volte che l’evento deve essere eseguito, sia il suo intervallo temporale di esecuzione.
Modificare o Cancellare un evento
Proprio come un trigger o una normale tabella, un evento può essere modificato o cancellato. Per cancellare un evento basta eseguire il seguente comando:
DROP EVENT [IF EXIST] event_name;
Per modificarlo, invece, ci possiamo servire del comando ALTER
.
Di seguito due possibili esempi per modificare il nome o la periodicità di un evento:
Esempio 1
ALTER EVENT my_event
RENAME TO your_event;
Esempio 2
ALTER EVENT my_event
ON SCHEDULE
EVERY 12 HOUR
STARTS CURRENT_TIMESTAMP + INTERVAL 4 HOUR;
Quest’ultimo esempio modifica lo schedule dell’evento my_event in modo che venga eseguito da subito e poi ogni 12 ore con un intervallo di 4 ore.
Esempio
CREATE EVENT my_event
ON SCHEDULE EVERY '1' MONTH
STARTS CURRENT_TIMESTAMP
DO
BEGIN
-- codice
END;
Questo è un pratico esempio in cui creiamo un evento, chiamato my_event, che verrà eseguito una volta al mese, a partire da quando verrà registrato allo scheduler, ovvero da CURRENT_TIMESTAMP.
Tra BEGIN
ed END
andranno inseriti i comandi che dovrebbero essere eseguiti una volta al mese. Ovviamente anche una chiamata a una stored procedure è una valida possibilità.