IDManager: modifiche ai DB e transazioni
linkIntroduzione
La pubblicazione di una applicazione web tramite IDManager può richiedere una o più modifiche allo schema delle tabelle dei database utilizzati dall'applicazione. Per esempio l'aggiornamento di una applicazione potrebbe richiedere l'aggiunta di nuovi campi o nuove tabelle nel database utilizzato dall'applicazione.
IDManager esegue la seguente procedura durante la pubblicazione di una applicazione web:
- apre una transazione su tutti i database
- inserisce, modifica o elimina i file dell'applicazione così come richiesto da In.de in fase di preparazione dei dati di pubblicazione
- effettua tutte le modifiche allo schema delle tabelle dei database
- esegue il Commit di tutte le transazioni aperte nel punto 1.
I database Access, MySql e Oracle non sono in grado di annullare eventuali modifiche allo schema delle tabelle del database. Infatti, tali database non permettono modifiche allo schema delle tabelle all'interno di una transazione e quindi tali operazioni non possono essere annullate tramite l'operazione di Rollback della una transazione.
Oracle, per esempio, considera le modifiche allo schema come modifiche che non possono avvenire in transazione. In particolare esegue automaticamente l'operazione di Commit di una transazione prima di eseguire comandi che riguardano lo schema del database (come indicato qui). Per esempio le seguenti operazioni:
Per questo motivo se In.de rileva che la procedura di pubblicazione richiede modifiche allo schema delle tabelle di un database Access, MySql o Oracle mostra un messaggio all'utente. Tale messaggio informa il programmatore che se si manifestano problemi durante la procedura di pubblicazione dell'applicazione IDManager potrebbe non essere in grado di ripristinare l'applicazione allo stato precedente all'avvio della procedura di pubblicazione come avviene, invece, nel caso di SqlServer, Postgres e DB2.
Oracle, per esempio, considera le modifiche allo schema come modifiche che non possono avvenire in transazione. In particolare esegue automaticamente l'operazione di Commit di una transazione prima di eseguire comandi che riguardano lo schema del database (come indicato qui). Per esempio le seguenti operazioni:
1. insert into TABLE(f1, f2, f3) values ('1', '2', '3') 2. insert into TABLE(f1, f2, f3) values ('4', '5', '6') 3. alter table TABLE add column f4 number(4) default 1 not null 4. insert into TABLE(f1, f2, f3) values ('7, '8', '9') 5. rollbackeseguite su un database Oracle generano un risultato inatteso. Per cominciare Oracle non ha una gestione delle transazioni come Sql Server. Ogni istruzione SQL non viene direttamente eseguita dal database ma viene eseguita in una sorta di area temporanea chiamata 'rollback segment'. Fino a quando non viene eseguita l'istruzione Commit le operazioni non vengono eseguite fisicamente sul database. Se, però, si tenta di eseguire un'istruzione che modifica lo schema delle tabelle del database, come per esempio l'istruzione 3 indicata sopra, Oracle effettua automaticamente il Commit delle operazioni raccolte fino a quel momento PRIMA di eseguire l'istruzione che riguarda lo schema. Poi esegue l'operazione sullo schema. Oracle, quindi, non è in grado di eseguire modifiche allo schema in maniera sicura ovvero una volta eseguita l'istruzione SQL di modifica dello schema non è più in grado di tornare indietro riportando il database allo stato originale.
Per questo motivo se In.de rileva che la procedura di pubblicazione richiede modifiche allo schema delle tabelle di un database Access, MySql o Oracle mostra un messaggio all'utente. Tale messaggio informa il programmatore che se si manifestano problemi durante la procedura di pubblicazione dell'applicazione IDManager potrebbe non essere in grado di ripristinare l'applicazione allo stato precedente all'avvio della procedura di pubblicazione come avviene, invece, nel caso di SqlServer, Postgres e DB2.
Ultima modifica: 24/08/2021 / Validità: da 10.1.4450