Dovrei unire le migrazioni dei database prima del rilascio?

Question

Dovrei unire le migrazioni dei database prima del rilascio?

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

2

Durante il processo di sviluppo possono apparire molte migrazioni. C'è qualche motivo per tenerli invece di unirli tutti insieme?

Diamo un'occhiata a un semplice esempio.

Durante lo sviluppo introduciamo un nuovo modello Person :

public class Person {
    public int Id { get; set; }
    public string Name { get; set; }
}

La migrazione # 1 crea una nuova tabella Persons con due campi nel database.

Successivamente abbiamo deciso di avere bisogno di un altro campo - Surname . La tabella di modifica n. 2 della migrazione aggiunge un nuovo campo.

Successivamente abbiamo deciso di introdurre un nuovo modello correlato, quindi Migration # 3 crea una nuova tabella e modifica Persons aggiungendo la chiave esterna.

Successivamente abbiamo deciso di rimuovere Surname . La migrazione n. 4 modifica la tabella rimuovendo la colonna.

Successivamente abbiamo deciso di rinominare la forma plurale di Persons in Person . La migrazione # 5 rimuove tutte le chiavi esterne, la tabella dei caratteri latini rinominandola, crea nuove chiavi esterne.

Alla fine abbiamo un sacco di migrazioni che fanno il lavoro indietro di un tempo per creare e rimuovere alcuni campi che non abbiamo bisogno nella versione finale. Questi campi, insieme ad altre possibili azioni di migrazione, sono solo una parte della storia dello sviluppo, ma non ne abbiamo davvero bisogno.

Quindi stavo pensando a cosa fare se ripristino il database al primissimo stato, rimuovi tutte le migrazioni e poi ne creo uno nuovo, che farà solo azioni nessune per portare un database al suo stato finale, riducendo un numero possibilmente enorme di migrazioni e azioni exessive a una sola migrazione diretta.

È una buona idea o è considerato un anti-pattern?

database migration entity-framework efcore

posta Exerion 21.09.2018 - 09:52

fonte

3 risposte

1

Le migrazioni verranno applicate automaticamente al momento della distribuzione del sistema. È molto improbabile che i comandi DDL in SQL dominino il tempo richiesto da un'installazione, quindi la cosa più appropriata da fare non è preoccuparsi di questo dettaglio di basso livello del sistema. Consolidarli tutti richiederebbe lavoro e non contribuire praticamente a nulla per il risultato, quindi è il tipo di compito con priorità più bassa che dovresti lasciare fino a quando non c'è assolutamente nulla di più urgente da fare nel progetto.

risposta data 21.09.2018 - 10:54

fonte

1

Ho visto le migrazioni arrotolate per l'implementazione in grandi aziende. Non lo definirei un pattern anti.

EF è un caso un po 'strano, ma in generale si vuole fare molta attenzione con le migrazioni DB. L'approccio più comune che ho visto è quello di rigenerare e poi lavorarli a mano.

Ciò consente di testarli su DB con volumi di dati simili alla produzione per garantire che funzionino correttamente e non causino problemi di prestazioni. Inoltre, vorrai assicurarti di avere degli script di rollback che possono essere applicati ecc.

Infatti, dopo averli uniti tutti insieme, potresti volerli dividere nuovamente per consentire un'implementazione graduale con compatibilità con le versioni precedenti o altri requisiti.

È uno sviluppatore coraggioso che aggiorna solo i suoi oggetti e consente a EF di capire cosa fare con il DB di produzione. (sebbene tbf MS ne faccia un buon lavoro)

risposta data 21.09.2018 - 11:46

fonte

Leggi altre domande sui tag database migration entity-framework efcore

Esiste una strategia duratura per la creazione di applicazioni front-end Usando json come database con EF, come posso collegare EF e il file json durante l'inizializzazione di DbContext?

score 2 · Accepted Answer

Questo è ok fintanto che sei sicuro al 100% che le migrazioni unite non colpiranno mai un database che si trova in uno stato intermedio (quindi, per esempio, la colonna Surname è lì, anche se non dovrebbe).

Questo dipende dal modo in cui si controlla il processo di distribuzione (in particolare il deplyoment delle migrazioni). Nota che questo non è necessariamente limitato ai rilasci di produzione: devi anche sapere quali stati intermedi potresti avere nel tuo ambiente di test, e se hai un team di sviluppo più grande in cui ogni dev ha il proprio db per scopi di test locali, questo potrebbe anche essere influenzato dal potenziale stato dei diversi ambienti di sviluppo.