Verificare che lo schema del database di destinazione sia conforme a quanto contenuto in Entity Framework?

Question

Abbiamo un processo in cui i nostri script di tipi di database cambiano (e li versioni con Juneau) al nostro database di applicazioni fuori banda con la nostra base di codice. Sono bravi a tenere conto che le nuove colonne sono nulle e non cancellano i dati esistenti, ma a volte una colonna di rinomina si insinua in quella non completamente comunicata. Quindi apporteranno alcune modifiche allo schema del database su un server di test, aggiorneremo Entity Framework per lavorare con tali modifiche e quindi eseguiremo il nostro codice. Questo processo funziona correttamente, eccetto per quando è il momento di distribuire.

Abbiamo impostato TFS per distribuire la build corretta sui server appropriati, ma non è garantito che il database per quell'ambiente sia stato aggiornato. Non ci interessa se campi extra/tabelle/viste/ecc. esistono nel database di destinazione, ma vogliamo modificare la build per verificare che il database contenga almeno tutto ciò di cui EF è a conoscenza.

Ho guardato this question, ma non ho bisogno che lo schema corrisponda esattamente. Inoltre, non vogliamo creare/modificare direttamente il database. E this question sembra che stia cercando di raggiungere un ideale simile, ma ancora non proprio quello che stiamo cercando di ottenere. Vogliamo solo un test di integrazione per verificare che la nostra versione di EF funzioni con lo schema di destinazione.

Answer 1

Mi chiedo perché si tenta di distribuire l'applicazione senza modifiche al database. La tua applicazione dipende dal database, quindi la distribuzione dovrebbe sempre essere eseguita dopo il database. Sembra che investirai molto tempo per sviluppare la convalida per correggere il tuo processo di distribuzione errato (dove la soluzione del problema è la soluzione corretta).

In ogni caso è possibile creare una "convalida" del database ma ci vorrà del tempo. Se si utilizza il file EDMX, è possibile aprirlo come XML e leggere la sua parte SSDL che descrive tutte le tabelle, le colonne, le relazioni, le viste previste (sotto forma di query SELECT SQL), le stored procedure e le funzioni. È possibile analizzare questa parte XML e utilizzare le viste del database di sistema (sys.tables, sys.columns, ...) per verificare se questi oggetti esistono nel database.

Un altro approccio può utilizzare il database diff. strumento per confrontare il database di test corrente con quello di destinazione. Ciò richiederà lo strumento che può essere eseguito dalla riga di comando e dovrai analizzare il suo output per trovare cambiamenti di rottura.