Gestione delle migrazioni controllate dalla versione del database utilizzando una lista / tabella

3

Non sono un esperto di questo settore, ma sono consapevole che esistono già soluzioni per la gestione delle migrazioni dei database nel controllo della versione, ad es. sqitch e liquibase . Tuttavia attualmente sto pianificando un piccolo progetto per hobby e anche sqitch sembra un fastidioso ammontare di spese cognitive.

Idea

Una migrazione è un (nome, azione su, giù azione). Stavo pensando di mantenere una singola tabella di colonne (la tabella delle migrazioni ) nel database SQL contenente nomi univoci di tutte le migrazioni che erano state eseguite. Quindi nel codice sorgente controllato dalla versione ci sarebbe una lista (la lista delle migrazioni ) con l'ordine delle migrazioni da eseguire.

Pro:

    I conflitti
  • ( chiave ) nella lista delle migrazioni verrebbero rilevati dal software di controllo della versione, ad es. git, e poi risolto manualmente;
  • un database può facilmente aggiornarsi eseguendo le migrazioni nella lista delle migrazioni che non si trovano nella tabella delle migrazioni nell'ordine in cui appaiono nella lista;
  • un database di sviluppo può eseguire il rollback agli schemi precedenti eseguendo l'azione in giù per tutte le migrazioni nella tabella di migrazione che si verificano prima della migrazione di destinazione nella elenco delle migrazioni ( potrebbe essere necessario aggiungere un timestamp in modo che possano essere rimossi nell'ordine corretto);
  • è abbastanza semplice che io stia bene con la scrittura di un'implementazione ad-hoc per un progetto.

Contro:

  • l'ovvia critica xkcd ;
  • forse qualcuno l'ha già fatto e non ha funzionato;
  • forse nessuno lo ha fatto prima perché non funzionerà.

Domanda

Quindi la mia domanda è, dato che voglio gestire le migrazioni dello schema nel controllo di versione ma non voglio complicare le cose, la soluzione di cui sopra è una buona idea? Sono aperto ad altre soluzioni se sono in grado di rilevare o risolvere automaticamente i conflitti di migrazione e sono semplici.

    
posta Dave 17.11.2014 - 00:52
fonte

1 risposta

3

Il modo in cui si prevede di eseguire le migrazioni è essenzialmente lo stesso di Entity Framework per le applicazioni .NET. Ha una tabella DatabaseMigrations con una chiave che è la data / ora con una stringa univoca aggiunta ad essa.

Il codice di una particolare versione è progettato per funzionare con una particolare versione del database. Cerca la migrazione più recente nella tabella delle migrazioni e applica le migrazioni finché non ha lo schema del database necessario. Può anche eseguire migrazioni verso il basso, ma queste non sono automatiche.

Ecco dove si differenzia dalla soluzione: invece degli script di migrazione codificati come SQL che vengono eseguiti come script dal controllo della versione (se ho capito cosa ho letto correttamente), Entity Framework codifica le migrazioni come classi C # all'interno del programma così, dopo l'inizializzazione del database, cercherà sottoclassi di "Migrazione" e le istanziate come appropriato. Puoi avere un'idea di come appare qui .

Penso che la soluzione che hai trovato sia buona. Se sei a tuo agio nell'implementazione, prova a farlo.

    
risposta data 18.11.2014 - 00:39
fonte

Leggi altre domande sui tag