2014-04-01 12 views
5

Il progetto su cui sto lavorando utilizza Entity Framework 4.3 e le migrazioni dei dati per mantenere aggiornato lo schema. Nel corso del progetto la cartella migrazioni è cresciuta e ora ha oltre 600 file. Questo è enorme. Ora abbiamo un binario che supera i 12 MB a causa di tutti i metadati della migrazione.Qual è il modo migliore per comprimere tutte le migrazioni di Entity Framework esistenti

Vorrei raggruppare tutti questi dati in un'unica migrazione e ricominciare. Le mie preoccupazioni sono:

  1. È possibile o causerà problemi con la cronologia di migrazione se rimuovo le migrazioni?
  2. Esistono delle guide per descrivere come eseguire questa operazione?

risposta

5

Primo: si consiglia di mantenere le migrazioni in un assieme separato in modo che non debbano essere pubblicate con l'applicazione. Potrebbe essere una semplice app per console che applica le migrazioni o una GUI di winforms che genera script. Ma non c'è motivo per essere implementato con l'app imo.

Secondo: capendo che si rinuncia alla possibilità di eseguire il rollback delle versioni precedenti, è possibile escludere dal progetto tutte le migrazioni precedenti, quindi generarne una nuova che dovrebbe quindi essere in grado di creare un database riflettendo il tuo modello attuale. Questo sarebbe il tuo nuovo punto di partenza. Ricorda che EF non genera sempre codice per fare tutto ciò che vuoi in una migrazione, quindi potresti avere del codice di migrazione scritto a mano in altre migrazioni che avresti bisogno di inserire.

+0

Idea fantastica per spostare le migrazioni in un altro assieme. Sai se questo è possibile con EF 4? Pensavo che le migrazioni dovessero vivere nello stesso progetto di DataContext. –

+1

La classe derivata DbMigrationsConfiguration deve solo essere in grado di vedere il tuo DbContext. Due modi per farlo. Si potrebbe avere un contesto separato nel progetto Migrazioni o si potrebbe aggiungere un riferimento al livello dati nel progetto Migrazioni in modo che possa vedere il contesto (i) lì. L'approccio che prendo è quello di mantenere le mie entità e le classi di mappatura delle entità nei propri progetti separati. Nel mio progetto Migrations ho un contesto speciale che non definisce alcun DbSet, ma carica dinamicamente tutte le mie classi di mappatura delle entità usando 'modelBuilder.Configuration.AddFromAssembly()' –

+0

Mi piace la separazione che hai creato. Permette comunque agli sviluppatori di utilizzare Add-Migration e Enable-Migration dalla console? –

0

Non sicuro delle versioni precedenti, ma se siete qui cercando la stessa soluzione per EF Core. Dovresti riuscire a eliminare ModelSnapshot ed eseguire nuovamente la migrazione per creare un foglio pulito.