Eventi di salvataggio dati

Chiudiamo il ciclo degli eventi documentali con la fase di salvataggio dei dati, dove vi ricordo anche la richiesta di cancellazione è inclusa: la fase di salvataggio dati inizia sempre con quello che abbiamo visto nel tutorial precedente e precisamente con la validazione dei dati a cui è possibile sottoscriversi al relativo evento OnValidate: se un documento non passasse la validazione gli eventi di salvataggio non scatteranno.

La fase di salvataggio è formata da 3 step:

• Step Prima del salvataggio.
• Step preparazione Query ed esecuzione.
• Step Dopo il salvataggio.

Sarà possibile sottoscriversi agli eventi generati nelle fasi prima e dopo il salvataggio denominati BeforeSave e AfterSave.

L’evento BeforeSave è utile nel caso si voglia impostare il valore di alcune proprietà, proprio un attimo prima del salvataggio: l’evento non è adatto per controllare i dati perchè a quello scopo è presente l’evento OnValidate; quindi cosa potremmo fare nell’evento BeforeSave ? ad esempio se avessimo una proprietà denominata DataOraModifica, e volessimo valorizzarla ogni volta che si effettua un salvataggio, l’evento BeforeSave è quello corretto oppure nel caso di desideri alterare il comportamento standard di salvataggio.

Abbiamo fatto un'operazione simile anche nel caricamento: per esempio invece del caricamento da database carichiamo i dati da file o attraverso chiamate REST di tipo GET o POST e per il salvataggio dovremmo essere in grado di fare la stessa operazione ovviamente inversa; quindi bloccare il salvataggio standard e salvare in modalità autonoma: l’evento BeforeSave assolve a questo scopo.

Se il flusso di salvataggio rimane quello standard si prosegue con la preparazione della query da inviare al database, query preparata nel modo opportuno: per i nuovi record si utilizza l’istruzione INSERT, per gli aggiornamento UPDATE con le sole proprietà modificate ed infine DELETE nel caso di cancellazioni.

Conclusa la preparazione della query, la stessa viene inviata al database ed eseguita ed in caso di successo nel documento scatta l’evento AfterSave.

Faccio subito una precisazione relativa a come l’esecuzione query avviene: se il database e il driver supporta ciò che è denominato transazioni database l’intera operazione di esecuzione ne sfrutta le caratteristiche:

• il framework richiede al database di aprire una transazione DB.
• La query viene inviata al database.
• Il database esegue la query mantenendo sia lo stato dei dati precedente che lo stato dei dati a seguito della query in attesa di un comando di chiusura.
• In attesa del comando di chiusura, ogni query inviata viene eseguita ma mantenuta in un limbo con la stessa logica.
• Il comando di chiusura, atteso dal database è un comando di COMMIT o un comando di ROLLBACK: con Commit tutti i dati vengono resi permanenti, con Rollback i dati tornano agli stati precedenti l’esecuzione query.

L’intera fase di salvataggio documentale, se supportato dal database, sfrutta i principi della Transazione Database: la transazione viene aperta prima dell’invio della query di aggiornamento e solo a chiusura dell’evento AfterSave viene inviato il comando di COMMIT; abbiamo però proprio nell’evento After Save la possibilità di indicare al database di eseguire un ROLLBACK perché abbiamo ritenuto opportuno non salvare.

Uno potrebbe chiedersi ma perché indico di salvare e poi decido di non salvare più e tornare indietro? Mille motivi possono nascondersi dietro però’ prendiamo un caso del genere: due persone effettuano nello stesso momento una prenotazione per un appartamento, e lo effettuano nello stesso periodo: come faccio a prevenire questa situazione? Con questa modalità: prima salvo il record e poi nell’after save controllo con una query se ci sono record che si accavallano: se ne trovo uno che si accavalla allora blocco tutto; perché non l’ho fatto nella OnValidate? Per un motivo di tempistiche, preferibile controllare quando tutti i dati sono sul database.

Aggiungiamo proprio questo controllo ricordandoci sempre che nell’evento After Save i dati sono già memorizzati anche se lo stato documento è ancora come se non lo fossero: cosa intendo ? che posso chiedermi nell’evento ma il documento è Inserted ? è Modified ? è Deleted ? : diciamo che mi chiedo sempre con le proprietà boolean che conosciamo come era lo stato prima del salvataggio anche se il salvataggio è già avvenuto.

Albero di progetto, documento Prenotazione, cominciamo aggiungendo un metodo o meglio Aggiungi Procedura:

public boolean canBooking() {
//Questo metodo mi dovrà dire se il record attuale risulta duplicato
Boolean canBook = false;
canBook = true;
return canBook;
}

Ora aggiungiamo l’evento AfterSave e scriviamo il codice opportuno.

Event AfterSave {
Boolean canBook = true;
If (not (deleted)) {
canBook = canBooking();
}
If (not(canBook)) {
// ESEGUO IL ROLLBACK
Cancel = true;
//Avviso con un errore
addDocumentError(“Disponibilità posti esaurita”)
}
}

La sottoscrizione all’evento AfterSave ci consente di eseguire operazioni mirate ad ogni salvataggio del documento, senza preoccuparsi dove il salvataggio è stato richiesto se via codice o da interfaccia. L’evento AfterSave scatterà e salverà oppure annullerà l’operazione sul database.