DotNet migracje ef automatyzacja: Wykrywanie zmian w migracjach

Question

używam następujący CLI dla DB migracji:

1. dotnet ef migrations add <Name-of-Migration>
2. dotnet ef database update

Jednakże szukam sposób, aby tak się stało automatycznie: po wykryciu zmiany w Modelu.

Do tej pory udało mi się wyeliminować krok 2, wykonując następujące czynności w Startup.cs:

private void SetupDatabase(IApplicationBuilder app) 
    { 
     using (var serviceScope = app.ApplicationServices.GetService<IServiceScopeFactory>().CreateScope()) 
     { 
      var context = serviceScope.ServiceProvider.GetRequiredService<ApplicationDbContext>(); 
      //Migate any pending changes: 
      context.Database.Migrate(); 
     } 
    } 

ten migruje żadnych oczekujących zmian stworzone przez robi: dotnet ef migrations add <Name-of-Migration> ale nie dodać do migracji wszelkie zmiany w modelu. Jak zautomatyzować to migrations add?

Answer 1

Updated: Jest możliwe, aby przejść pierwszy etap generowania migracji automatycznie z kodu, decyzji projektowych, które ja osobiście nie zgadzam. Nadal nie jest to możliwe w twoim docelowym EF7, tak jak początkowo powiedziałem (został usunięty z EF7 wydaje się, jak wspomniano, in this SO post, a także na this blog post przez member of Microsoft EF team wspomniana w komentarzach Ivana), ale testowane w EF6 po odpowiedzi Martina. Drugi krok można zautomatyzować, ponieważ już to odkryłeś, więc nie będę go ponownie odtwarzał.

Kroki w pierwszym etapie są następujące (w ASP.NET MVC aplikacji Web z EF6):

1. w projekcie (który powinien być uruchomiony już w niektórych modelach w stanie spójnym) przejdź do konsoli menedżera pakietów i uruchom Enable-Migrations –EnableAutomaticMigrations. Jeśli twoja aplikacja ma jeden kontekst DB, to również zastosowała tam zmiany.
2. Teraz przejdź do istniejącego modelu i dodaj tam nowe pole, np. public String TestField { get; set; }
3. jako kod pierwszy automatyczne migracje są NA, nie trzeba ponownie uruchomić komendę Add-Migration (mam nadzieję, że ja podkreślić w dalszej części tej odpowiedzi), wystarczy uruchomić Update-Database i DB powinny być aktualizowane pozwalając aplikacja działa dobrze.

Dlaczego monitoring automatyczna zmiana modelu do generowania i bazy danych są automatycznie uaktualniane może rykoszetem czasami (moim skromnym zdaniem iz MSDN page):

• Automatyczne migracje przyzwyczajenie pracować zmiany ostrości zmienia nazwy, jak na MSDN.
• W przypadku dodawania pierwotnych typów pól należy uwzględnić istniejące dane i rozważyć ręczne migracje w tym scenariuszu.
• Można przeplatać migracje automatyczne i oparte na kodzie, ale nie jest to zalecane w scenariuszach rozwoju zespołu. Jeśli należysz do zespołu programistów używających kontroli źródła, powinieneś używać wyłącznie migracji automatycznych lub migracji opartych wyłącznie na kodzie. Biorąc pod uwagę ograniczenia migracji automatycznej, MSDN zaleca stosowanie migracji opartych na kodzie w środowiskach zespołowych.
• Dobrze jest potwierdzić, że zmiana modelu jest zamierzona i nie była wynikiem niektórych resztek kodu podczas wprowadzania zmian, coś, co może się zdarzyć, i zautomatyzowanie całego procesu może spowodować takie zmiany w DB.
• Migracja, która jest generowana, nie zawsze jest zoptymalizowana i/lub nie powiodła się z powodu pewnych ograniczeń danych lub podobnych problemów, a zatem powinna zostać sprawdzona.
• Nawet baza danych aktualizacji przekroczyła limit czasu dla danych produkcyjnych w niektórych przypadkach, gdy było zajęte mnóstwo danych podczas migracji. Musieliśmy wtedy ręcznie uruchomić go zdalnie i zrestartować serwer.

Powyższe może nie mieć zastosowania do wszystkich, ale należy się zastanowić, dlaczego zgadzam się z decyzją projektową, że nie spowoduje automatycznego generowania migracji i stosowania do bazy danych.

Wszyscy rozważający włączenie automatycznych migracji powinni na pewno przeczytać MSDN page po więcej przykładów i braków.

Answer 2

Entity Framework 4.3 has introduced the Automated Migrations.

Chociaż zgadzam się z odpowiedzią Hassana stwierdzającą, że to może być bardzo trudne, ta opcja faktycznie istnieje.

Oto krótki życiorys:

1. Po włączeniu Migracje, należy podać parametr w konsoli Menedżer pakietów:

enable-migracje -EnableAutomaticMigration: $ true

2. A Klasa konfiguracji będzie automatyczna lly generowane:

   public Configuration() 
   { 
       AutomaticMigrationsEnabled = true; 
   
       //Set this parameter to true if you want to let auto-migration delete data when a property is removed from an entity. 
       //Not setting this will result in an exception when migration should remove a column. 
       AutomaticMigrationDataLossAllowed = true; 
   } 
   

3. Ustaw DB initializer w swojej klasie Context

   Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDBContext, MyConfigurationClass>("MyConnectionString")); 
   

I tam pójdziesz, zmienić swój model i zobaczyć zmiany ...

I Nadal nie jestem pewien, czy będę go używał, ponieważ chcę zmienić moją bazę danych, kiedy tak powiem ...