Czy zmiana nazwy tabeli EF __Migration History jest niebezpieczna? - sql-server, framework encji

Wczoraj zapytałem to pytanie o zmianie nazwy __Migration History tabela generowana przez Entity Framework przy korzystaniu zKod Pierwsze podejście. Podany link był pomocny w powiedzeniu, jak robić to, czego chcemy (i "chcę" mam na myśli to, do czego jesteśmy zmuszani przez nasze DBA), ale także zostawiliśmy nieco niespecyficzne i strasznie brzmiące ostrzeżenie, które mówi,

Słowa ostrożności

Zmiana tabeli historii migracji jest potężnaale musisz być uważaj, aby nie przesadzić. Środowisko wykonawcze EF obecnie nie sprawdza, czy dostosowana tabela historii migracji jest zgodna z środowisko wykonawcze. Jeśli nie, twoja aplikacja może się zepsuć w czasie wykonywania lub zachowywać się w nieprzewidywalny sposób. Jest to jeszcze ważniejsze, jeśli używasz wielu konteksty na bazę danych, w którym to przypadku wiele kontekstów może używać tego samego tabelę historii migracji do przechowywania informacji o migracji.

Próbowaliśmy użyć tego ostrzeżenia, aby uzasadnić zZespół DBA, mówiąc im, że nie powinniśmy mieszać się do rzeczy, ponieważ "tutaj są smoki" Ich odpowiedź brzmiała: "To brzmi bardziej jak niebezpieczeństwo polega na zmianie treści lub struktury tabeli, a nie nazwy. Śmiało, spróbuj tego i zobacz, co się stanie. "

Czy ktoś tutaj zmienił nazwę __Migrations History tabela i jaki był wynik? Czy to jest niebezpieczne?

Odpowiedzi:

Możliwa jest zmiana nazwy tabeli historii migracji. Ale musisz powiedzieć EF to, dzwoniąc do HasDefaultSchema metoda z nazwą schematu w OnModelCreating metoda twojego DbContext klasa:

public partial class CustomerDatabasesModel : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.HasDefaultSchema("CustomerDatabases");

// Fluent API configuration
}
}

To spowoduje, że EF utworzy prefiks "CustomerDatabases" dla wszystko tabele bazy danych. W tym przykładzie "CustomerDatabases" zastępuje standard przedrostka "dbo" w tabelach. Twoja historia migracji będzie miała nazwę CustomerDatabases.__MigrationHistory.

Tak więc zmieniasz nazwę właściciela bazy danych (pierwsza część), druga część "__MigrationHistory" pozostaje taka sama.

Scenariusz użycia:

Zwykle robisz to, jeśli pracujesz z więcej niż jedną DbContext. Więc możesz mieć więcej niż jedną tabelę MigrationHistory w jednej bazie danych, po jednej dla każdego kontekstu.

Z tego powodu powinieneś dokładnie przetestować to i wcześniej wykonać kopie zapasowe bazy danych.

Sprawdź także tę odpowiedź: Entity-Framework: On Database, wiele DbContexts