Przy uruchamianiu aplikacji na nowo zdefiniowanej bazie muszę na początku odpalić inicjalną migrację, która postawi mi bazę.
Następnie muszę zasilić bazę użytkownikiem technicznym i puścić pozostałe migracje.
Zbiorczo mogę to zrobić z poziomu DbContext.Migrate()
Chcę wykonać coś takiego update-database InitialMigration tylko, że z kodu.
Dlaczego nie wrzucisz użytkownika technicznego jako część migracji?
@Saalin: Gdyż muszę użyć UserManagera aby powstał hash hasła i inne tego typu dane, a za pomocą migracji jest to niemożliwe.
Chyba, że dla inicjalnej migracji zedytuje kod migracji, dopiszę na końcu metody "Up" migrationBuilder.InsertData().
Tylko, że będę musiał tam wrzucić już zahashowane hasło. Jakoś mało mi to elegancko wygląda aby grzebać w plikach migracji.
Przecież modyfikacja migracji to standardowa praktyka. Poza tym - nie musisz hardkodowac hasła, wygeneruj je podczas migracji i wyrzuć gdzieś do logów, tak żeby poweruser mógł je odczytać.
@Saalin: skoro modyfikacja migracji to nie jakaś zbrodnia za którą kiedyś jakiś koder purysta mógłby mnie zganić to luzik.
Co do hasła to pisałem o zahashowanym, a nie zahardkodowanym.
No tak czy siak, nie wiem czy umieszczenie stałego hasha jest takie idealne, osobiście wolałbym, żeby domyslne hasło było generowane per instancja niezależnie. Co kto lubi.
Co do koderów purystów to myśl bardziej jakie konsekwencje ma dany wybór. W tym wypadku - czy modyfikacja migracji wpływa na coś negatywnie? Poza tym migrację nie ogarnąć wszystkiego, np. widoków czy triggerów (gdyby przyszła Ci ochota na jakis).
Program.cs
if (_context.Users.Count == 0)
{
add new user("admin", "123");
}
;)
a tak w ogóle jaką macie opinie nt. mechanizmu migracji? bo mi to chyba więcej problemów generuje niż rozwiązuje :D :D
@WeiXiao: ja nie lubię migracji EF, już bardziej wolę FluentMigrator czy nawet Flyway.
Migrację same w sobie i wersjonowanie schematu czy schemat jako kod jak najbardziej tak.
WeiXiao napisał(a):
Program.cs
if (_context.Users.Count == 0) { add new user("admin", "123"); };)
Nie takie to proste... Gdyby tylko istniała taka tabela. Jednak jak odpalasz na czystej bazie aplikację to tabela User jeszcze nie istnieje.
Z kolei kolejne migracje posiadają inserty, które to zawierają id użytkownika technicznego, który to jest wskazywany przy tych insertach jako użytkownik, który utworzył wpisy w bazie.
Tzw motyw "co było pierwsze? jajo czy kura?"...
Problem mi się dopiero ujawnił gdy chciałem odpalić aplikację na czystej bazie.
Naprawdę nie rozumiem problemu... Tworzysz strukturę bazy danych w migracjach. Podczas odpalenia systemu (lub po utworzonej strukturze), zaczynasz ją wypełniać danymi... Tworzenie struktury do danych ma się nijak. A jeśli musisz utworzyć tabelę na podstawie jakiegoś rekordu w innej tabeli podczas tworzenia bazy, to masz coś baaaardzo nie tak.