Migracja baz danych dla Entity Framework 4

Question

Gram w Entity Framework 4, używając podejścia opartego na modelu do generowania skryptu bazy danych z moich encji. To jest świetne, ale nie jestem pewien, jak to działa, jeśli chodzi o wersjonowanie bazy danych. Zgaduję, że jeśli chciałbym użyć aktywnej struktury migracji rekordów, musiałbym pracować na odwrót i generować moje jednostki z mojej bazy danych? Czy istnieje sposób na prawidłowe zastosowanie podejścia opartego na modelu i odpowiednią wersję bazy danych?

Answer 1

ten zostanie wkrótce jako pakiet Nuget zwane EntityFramework.Migrations

Demo zostało przeprowadzone przez Scott Hanselman na TechEd 2011 (dostępna online pod http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349). Odpowiednia sekcja jest 45 minut w

W skrócie, po zainstalowaniu pakietu, można wprowadzić następujące wartości w konsoli Menedżer pakietów wygenerować skrypt zmian w bazie.

migrate -script 

UPDATE (13 -Nov-2011)

Kompilacja alfa 3 tego pakietu jest już dostępna na NuGet. Zamiast używać wymienionego powyżej polecenia cmdlet migrate -script, używa on polecenia cmdlet Add-Migration <migrationname>. A walk-through of its use można znaleźć na blogu zespołu ADO.NET.

UPDATE (14-lut-2012)

Funkcjonalność ta jest obecnie dostępna jako część głównego EntityFramework NuGet package, począwszy od wersji 4.3. An updated walk-through przy użyciu EF 4.3 można znaleźć na blogu zespołu ADO.NET.

Answer 2

Cóż, jeśli chcesz pracować jak ActiveRecord, musisz pracować jak ActiveRecord. :)

Jeśli jednak chcesz korzystać z migracji modelu, ale nadal korzystać z migracji, będzie to możliwe, ale będzie wymagać dodatkowej pracy w Twoim imieniu. Model-pierwszy wygeneruje skrypt zmiany bazy danych. Będziesz musiał wyodrębnić odpowiednie części do migracji, a także ręcznie pisać skasowane skrypty. Chociaż wiąże się to z pracą fizyczną, nie wydaje mi się to aż tak trudne.

Answer 3

Możesz wypróbować Wizardby: jest to narzędzie do zarządzania migracjami baz danych. Nie integruje się z EF (ponieważ jest prawie niemożliwe zintegrowanie się z nim w tym zakresie), ale wykonuje to zadanie.

Answer 4

ScottGu wspomina coś o tym w blog entry:

Jesteśmy również będzie wspieranie „migracje” cecha EF w przyszłości, która pozwoli na zautomatyzowanie/migracje skrypt schematu bazy danych programowo.

[EDIT]

myślę, że może być odniesienie do Entity Designer Database Generation Power Pack, jak odpowiedzieć Morteza Manavi w another SO answer.

Answer 5

Pracuję nad alternatywą dla biblioteki EF.Migrations - EntityFramework.SchemaCompare. Pozwala fizycznie porównać schemat bazy danych z modelem encji reprezentującym kontekst bazy danych (EF.Migrations tego nie robi). Można go uruchomić podczas inicjalizacji bazy danych lub ręcznie na żądanie.Rozważmy następujący przykład

#if DEBUG 
Database.SetInitializer(new CheckCompatibilityWithModel<DatabaseContext>()); 
#endif 

Będzie wyjątek podczas inicjalizacji bazy danych opisujących różnice między schematu db i modelu, jeżeli występują problemy z kompatybilnością. Alternatywnie można znaleźć te różnice w dowolnym momencie w kodzie ten sposób

using (var ctx = new DatabaseContext()) 
{ 
    var issues = ctx.Database.FindCompatibilityIssues(); 
} 

następnie o tych różnic/problemy z niekompatybilnością na rękach można albo zaktualizować schemat dB lub modelu.

To podejście jest szczególnie przydatne, gdy potrzebna jest pełna kontrola nad schematem bazy danych i projektowaniem modelu i/lub praca w zespole, w którym wielu członków zespołu pracuje na tym samym schemacie i modelu bazy danych. Może być również używany jako dodatek do plików EF.Migrations.

Widelec mnie na GitHub: https://github.com/kriasoft/data