Aktualizacja aplikacji, a wersja bazy danych

Witam.

Zacząłem się ostatnio zastanawiać nad jedną rzeczą. Nie mam doświadczenia komercyjnego, więc nie wiem jak to się robi, dlatego postanowiłem tutaj zapytać.
Powiedzmy mam jakąś aplikację, bez różnicy jaką, webową czy desktopową. Aplikacja korzysta z bazy danych poprzez Entity Framework z code-first z migracjami. Powiedzmy, że sprzedaję tę aplikację klientom. Ale po pewnym czasie wypuszczam aktualizację aplikacji, która obejmuje również zmiany w bazie danych. No i taki klient aktualizuje aplikację i przy pierwszym użyciu dbcontextu leci wyjątek o niezgodności struktury bazy i konieczności migracji.
Jak teraz klientowi zaktualizować bazę danych? Podczas pisania aktualizacji mam u siebie bazę testową i z poziomu Visual Studio dodałem migrację, zaktualizowałem swoją bazę danych, ale co w przypadku podpięcia bazy klienta? Jak to wtedy działa?

W duzych systemach czesto dostarcza sie tzw. skrypty migracyjne. Czyli skrypty ktore po odpaleniu odpowiednio updatuja DB. (Koniecznie pamietac o backupie!).
Spotkalem sie tez z opcja ze jak sie instalowalo patcha to automatycznie sprawdzal jaka jest wersja DB, i jak bylo trzeba to aplikowal zmiany. To jaka masz wersje bazy mozesz sobie trzymac w jakiejs tabeli.

Czasem tez po prostu na miejsce jecha; "jeden z naszych najlepszych specjalistow" i robil reczna migracje.

Ok, ale rozumiem, że sprawdzanie wersji bazy danych odbywało się z pominięciem EF, tylko przy użyciu SqlConnection powiedzmy? Bo przy pierwszym użyciu dbcontext wywali wyjątek.

Dziwię się, że uważasz, iż rzucony zostanie tutaj jakikolwiek wyjątek. Najprostszą, taka zupełnie najbardziej "prostacką" techniką jest po prostu trzymanie w tabeli historii wersji aplikacji. Kiedy aktualizujesz klienta i wersja bazy się nie zgadza to odpalasz kod, który bazę zaktualizuje, nie ważne czy przy pomocy EF czy czegokolwiek innego, bo to nie ma znaczenia w ogóle.

Robiłem takie rzeczy za pomocą EF bez mechanizmu migracji, czy za pomocą NH i też działało, bez żadnych wyjątków. To zwyczajnie kwestia podejścia.

System.InvalidOperationException: 'The model backing the 'SmContext' context has changed since the database was created. Consider using Code First Migrations to update the database

Jak trza było dołożyć tabelki to dokładałem encje, mapowałem i odpalałem odpowiednią metodę, która wszystko realizowała, w oparciu o numer wersji programu i bazy. Co innego jakieś dropy kolumn w tabelach etc..., bo tutaj rzeczywiście migracja w EF się przydaje ale wciąż jest to kwestia organizacji. Z takim wyjątkiem się nie spotkałem ale też z EF nie mam jakichś strasznie dużych doświadczeń. Zwykle dołożenie nowych tabel czy mapowań realizowane było kompletnie bez problemu więc zapewne coś robisz nieprawidłowo.

PS: odpowiadaj w postach, a nie w komentarzach.

Właśnie pewnie coś robię źle.

Wyjątek taki występuje, gdy usunąłem trzy tabele, jedną dodałem i jedną zmodyfikowałem oraz po tym nie wykonałem migracji tylko od razu uruchomiłem program i próbowałem użyć funkcji, która korzysta z bazy danych.

Wyjątek taki występuje, gdy usunąłem trzy tabele, jedną dodałem i jedną zmodyfikowałem oraz po tym nie wykonałem migracji tylko od razu uruchomiłem program...

To wiele wyjaśnia, w związku z tym wyjątkiem.

Jeśli usunąłeś tabele i nie zaktualizowałeś modelu to sam sobie w tym momencie odpowiedziałeś. ;)
Albo dropujesz i grzebiesz w bazie przez DbMigration (choć jak mówiłem z EF mam niewiele doświadczeń) albo robisz coś pod spodem i ręcznie aktualizujesz model.
Model został utworzony i baza istnieje, a że odwołuje się do tabel, których nie ma to Twoja wina, bo źle to zaplanowałeś i nie skorzystałeś z odpowiednich narzędzi.

Model sam się nie zaktualizuje, no chyba, że zrobiony został przez kreator to tak. Wtedy można to zrobić jednym kliknięciem, aczkolwiek to bardzo ciężka opcja. ;-) W code first to Ty musisz o to dbać.

Pamiętaj, że nazwa metody OnModelCreating dobitnie świadczy o tym kiedy zostanie odpalona i tym samym wyjaśnia dlaczego nie działa Ci to co chciałeś zrobić.

PS: Kurcze, pińcet razy będę edytował te swoje posty... i tak znajdę coś co mi się nie spodoba... i tak bez przerwy, ilekroć coś napiszę. ;)

No zrobiłem trochę odwrotnie. Usunąłem dwie klasy z modelu i dwie zmodyfikowałem. Nie ruszałem nic w bazie.

Owszem nie odpalam migracji, bo jak ją uruchomię to mi zaktualizuje bazę danych, a przecież klient ma starą wersję. Jedyną różnicą pomiędzy tym co ja teraz mam, a co będzie miał klient to to, że on dostanie wersje aplikacji z klasami migracji.

Edit: Ok dodałem migrację, ale nie zrobiłem update-database, czyli jest stan taki, jaki będzie miał klient po dostaniu nowej wersji programu. I przy odpaleniu rzuca właśnie tym wyjątkiem.

No jeśli zmodyfikowałeś klasy modelu, a nie ma ich odpowiedników w bazie to nie ma się co dziwić, że rzucany jest wyjątek. To logiczne.

No, ale właśnie taką sytuację będzie miał klient. Dostanie aktualizację programu ze zmienionymi klasami modelu, a bazę będzie miał w starej wersji.

Teraz załóżmy mam w bazie wersję bazy danych, którą wyciągam z bazy z pominięciem EF. Jeśli się zgadza to jest ok program może działać. Jeśli nie to uruchamiam skrypt, który aktualizuje bazę danych. Pytanie tylko, czy ma to być skrypt sql, który będę dokładał do aplikacji, czy może jakoś da się to wykonać korzystając z EF?

Pytanie tylko, czy ma to być skrypt sql, który będę dokładał do aplikacji, czy może jakoś da się to wykonać korzystając z EF?

Da się to zrobić przez DbMigration albo za pomocą SQL'a. Tak jak mówiłem; to kwestia podejścia, niemniej jednak skoro masz Entyty Frejmłork to użyj raczej jego, zamiast bawić się w SQL'e.

A czy masz może jakiś przykład jak to wykonać, albo pod jakim hasłem szukać? Ja odpalam migracje z konsoli nugeta w VS, u użytkownika musiałaby zostać odpalona z kodu taka migracja.

Jak wspomniałem wcześniej; niewiele robiłem w EF, (za to wiele robiłem upgade'ów wersji programu i bazy), więc może coś takiego Ci pomoże:

• https://docs.microsoft.com/pl-pl/ef/ef6/modeling/code-first/migrations/#automatically-upgrading-on-application-startup-migratedatabasetolatestversion-initializer
• https://blog.rsuter.com/automatically-migrate-your-entity-framework-core-managed-database-on-asp-net-core-application-start/

Hmm... generalnie jeśli nie znasz dobrze mechanizmu migracji to można zmiany pojechać choćby przez procedury składowane albo czyste SQL'e, odpalane za pomocą EF.
Z drugiej strony skoro nie znasz dobrze mechanizmu to nie powinieneś wykorzystywać go względem swoich klientów. ;-)

Ok, pierwszy linka znalazłem kilka minut temu. Jednak da się to jakoś pogodzić z innym inicjalizerem? Obecnie mam podpięty swój initializer, który rozszerza CreateDatabaseIfNotExists i wypełnia danymi początkowymi. Da się jakoś to pogodzić?