Rozwiązanie znalazłem było:
Upewnij migracje auto są wyłączone. Jest tak, aby VS wygenerował skrypt (płynny kod api), abyśmy mogli dalej go dostosowywać, zamiast tylko go uruchamiać. Więc w klasie konfiguracji:
public Configuration()
{
AutomaticMigrationsEnabled = false;
}
Dodaj pole do klasy i ustawić go jako obliczane jak tak, to seter jest prywatny, ponieważ oczywiście nie można napisać do pola wyliczona:
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public string BreakdownNo { get; private set; }
Następnie wykonaj add-migration [xyz-name]
w Konsoli menedżera pakietów, aby wygenerować kod migracji, który pojawi się w folderze migracji o podanej nazwie.
Wewnątrz komentarzu migracji na zewnątrz kodu w Up()
i dodać niestandardowy SQL tak:
public override void Up()
{
//AddColumn("dbo.Calls", "BreakdownNo", c => c.String());
Sql("ALTER TABLE dbo.Calls ADD BreakdownNo AS ('BD'+RIGHT('00000'+ CAST(Id AS VARCHAR), 6))");
}
Czy to update-database
w PM i należy dodać kolumnę obliczoną prawidłowo.
zauważa ponadto: Jeśli masz złą formułę wtedy trzeba będzie powrócić migracji wykonując update-database -targetMigration: [name of migration to go back to]
następnie zrobić kolejny add-migration name
i zmienia swoją formułę tam, wykończenia z update-bazy. Może być lepszy sposób, ale to jest to, co znalazłem i wykorzystałem.
Nie znalazłem jednak sposobu, aby pole przetrwało.
To wydaje się być pytanie o „kolumny obliczane” zamiast „utrzymywały kolumny obliczane”. Nieprzerwane kolumny obliczeniowe to już inna kwestia. –