Entity Framework - Zmiana tabel bez utraty danych

0

Witam. Zastanawia mnie pewna kwestia dotycząca migracji w EF. Jak przeprowadzić aktualizację bazy dokonując zmian w istniejących tabelach bez utraty zapisanych danych? Weźmy przykładowo scenariusz gdzie projekt był tworzony od zera w Code First i została utworzona taka klasa z odpowiadającą jej tabelą w bazie:

class Order
{
public int OrderId {get;set;}
public int ProductId {get;set;}
public Product Product {get;set;}
public string CustomerName {get;set;}
public string CustomerSurname {get;set;}
}

Przykład jest oczywiście absurdalny. Załóżmy że taki model jest używany przez rok, powstała spora baza zamówień po czym ktoś odkrywa że masa klientów się powtarza i postanawia wyodrębnić właściwości Customer(...) do nowej klasy. Jak w takim wypadku dokonać migracji nie tracąc danych? Ewentualnie jak zrobić by własnoręcznie napisany skrypt został odpowiednio przetworzony przez EF?

2

Ja bym kompletnie pominął EF i zmigrował dane na bazie. Nie widzę sensu w próbie użycia EF w tym przypadku.

0

Czy EF nie będzie wtedy rzucać błędów? Co jeśli dokonamy drobnej zmiany w przyszłości, np. zostanie dodana nowa właściwość do klasy. Jak sobie z tym poradzą migracje EF?

2
Aventus napisał(a):

Przykład jest oczywiście absurdalny. Załóżmy że taki model jest używany przez rok, powstała spora baza zamówień po czym ktoś odkrywa że masa klientów się powtarza i postanawia wyodrębnić właściwości Customer(...) do nowej klasy. Jak w takim wypadku dokonać migracji nie tracąc danych?

  1. Utworzyć nową tabelę.
  2. Skopiować dane do nowej tabeli zachowując ich unikalność.
  3. Dodać FK do starej tabeli.
  4. Znaleźć wartość dla FK w nowej tabeli i wstawić ją w kolumnie starej tabeli.
  5. Wyłączyc nullowalność dla kolumny FK.
  6. Usunąć zbędne kolumny ze starej tabeli.

Punkt 4. może być bardzo nieefektywny jeśli byłby wykonywany przez EF.

Ewentualnie jak zrobić by własnoręcznie napisany skrypt został odpowiednio przetworzony przez EF?

Spróbuj z Add-Migration RunSqlScript albo: https://msdn.microsoft.com/en-us/library/dn857435(v=vs.113).aspx

Aventus napisał(a):

Czy EF nie będzie wtedy rzucać błędów? Co jeśli dokonamy drobnej zmiany w przyszłości, np. zostanie dodana nowa właściwość do klasy. Jak sobie z tym poradzą migracje EF?

Jeśli jakichś zmian nie będzie w migracjach, a potem je uruchomisz, to te zmiany stracisz. Sugeruję zdecydować się na jedną drogę działania i trzymać się jej przez cały czas życia aplikacji.

1
Aventus napisał(a):

Czy EF nie będzie wtedy rzucać błędów? Co jeśli dokonamy drobnej zmiany w przyszłości, np. zostanie dodana nowa właściwość do klasy. Jak sobie z tym poradzą migracje EF?

EF w trybie CF nie śledzi zmian na bazie więc możesz dodawać nowe obiekty do bazy do woli, nie powodując żadnych błędów.
EF w trybie CF śledzi natomiast stan twojego modelu w kodzie, więc jak dodasz nową właściwość wtedy rzuci wyjątkiem że model nie zgadza się z tym co on ma zapisane w tabeli _MigrationHistory.
Załóżmy że dla tej dodanej właściwości mamy już wcześniej utworzoną kolumnę w bazie, potrzebujemy zsynchronizować stan bazy ze stanem modelu:
Generujemy nową migrację, zakomentujemy w niej fragment odpowiedzialny za dodanie kolumny dla naszej nowej właściwości(bo ona już ona istnieje w bazie), czyli możemy nawet skończyć z pustą migracją.
Następnie aplikujemy (pustą) migrację na bazie, EF uaktualnia model zapisany w _MigrationHistory, a my możemy bezproblemowo korzystać przez EF z dodanej za plecami EF kolumny :).

więc doprecyzowując moja poprzednią odpowiedź:

  1. pierw dodajesz nowe tabele/kolumny do modelu w CF, dodajesz migracje i aplikujesz na bazie
  2. migrujesz dane na bazie bez użycia EF
  3. usuwasz zbedne tabele/kolumny z modelu CF, dodajesz migracje i aplikujesz na bazie

lub pierw robisz 2) na bazie, a potem 1 i 3 jednocześnie na modelu CF by przywrócić synchronizacje modelu z bazą.

1 użytkowników online, w tym zalogowanych: 0, gości: 1