Gestione delle modifiche di rottura (breaking changes)
Damiano Zaniboni
260
Like
Share
ReportSalve lettore, in questo articolo voglio parlarti di come gestire le modifiche di rottura o come troverai nei vari forum, documentazione, ecc, le cosidette “breaking changes”.
Che cos’è una breaking change? Si può definire tale, quando modifichi lo schema di una tabella che può causare una perdita di dati. La modifica della chiave primaria o la modifica del tipo di dati, la riduzione della lunghezza di campi stringa sono considerate modifiche di rilievo e che concorrono a una modifica di rottura.
Se sei abituato in C/AL, questi cambiamenti li vivevi abbastanza tranquillamente e li gestivi velocemente, perché dopo aver compilato, se non avevi cambiato la chiave primaria, potevi fare serenamente ForceSync. Con l’avvento di Business Central, questa cosa non è una prassi da considerare, ma puoi gestire i cambiamenti di schema alla maniera di Microsoft. A dovere di cronaca, in ambiente di test o Sandbox puoi usare ancora la funzione ForceSynch, basta indicarla nel file launch.json. Ti ricordo che questa opzione applicherà le modifiche allo schema indipendentemente dalla perdita di dati. Questo, però, non garantisce la prevenzione della perdita di dati stessa.
A dover di cronaca abbiamo anche la proprietà “Recreate”, questo valore è anche più “potente” rispetto a “ForceSync” perché eliminerà tutte le tabelle e le estensioni create nell’app per ricrearle da zero. Questa azione porterà alla perdita di dati e quindi ricreerà lo schema da zero.
Per gestire, quindi, le modifiche dobbiamo innanzitutto ragionare sulla modifica che vogliamo apportare. Ad esempio se la modifica è correlata a un campo, la prassi vuole che si renda obsoleto il campo e creare quello nuovo che lo va a sostituire, quindi scrivere una codeunit di aggiornamento per trasferire i dati dal vecchio campo al nuovo durante l’installazione.
Vediamolo con un piccolo esempio. Ho una tabella con 3 campi, un code[20], un text[100] e un decimal.
Se ora provassimo a cambiare il tipo del campo decimal in integer, quando andiamo a pubblicare avremo questo errore.
Andiamo, allora a creare un nuovo campo, rendiamo obsoleto quello esistente ed infine creiamo una codeunit di installazione che va a spostare il valore del vecchio campo sul nuovo.
E se dovessi cambiare la chiave primaria? In questo caso dovresti rendere obsoleta l’intera tabella, crearne una nuova e poi creare una codeunit di aggiornamento che trasferisce i dati. Quando compi questa operazione devi fare attenzione alle TableRelation: devi commentare tutte le table relation dei campi di cui fanno uso della tabella che renderai obsoleta.
Spero di averti dato qualche spunto di riflessione in più su come gestire le modifiche di rottura.
The post Gestione delle modifiche di rottura (breaking changes) appeared first on Damiano Zaniboni Blog.
*This post is locked for comments