protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropTable(name: "Cars");
migrationBuilder.DropTable(name: "Make");
}
}
Как видите, метод Up создает таблицы, столбцы, индексы и т.д. Метод Down удаляет созданные элементы. По мере необходимости механизм миграции будет выдавать операторы alter, add и drop, чтобы гарантировать соответствие базы данных вашей модели.
Конструирующий файл содержит два атрибута, которые связывают частичные определения с именем файла и классом, производным от DbContext. Ниже показан фрагмент листинга конструирующего класса с упомянутыми атрибутами:
[DbContext(typeof(ApplicationDbContext))]
[Migration("20201230020509_One2Many")]
partial class One2Many
{
protected override void BuildTargetModel(ModelBuilder modelBuilder)
{
...
}
}
Первая миграция создает внутри целевого каталога дополнительный файл, именуемый в соответствии с производным от DbContext классом, т.е. <ИмяПроизводногоОтDbContextКласса>ModelSnapshot.cs. Этот файл имеет формат, совпадающий с форматом конструирующего файла, и содержит код, который представляет собой итог всех миграций. При добавлении или удалении миграций данный файл автоматически обновляется, чтобы соответствовать изменениям.
На заметку! Крайне важно не удалять файлы миграций вручную. Удаление приведет к тому, что файл <ИмяПpoизвoднoгoOтDbContextKлacca>ModelSnapshot.cs утратит синхронизацию с вашими миграциями, по существу нарушив их работу. Если вы собираетесь удалять файлы миграций вручную, тогда удалите их все и начните сначала. Для удаления миграции используйте команду remove, которая будет описана ниже.
Если какая-то сущность задействована сразу в нескольких DbContext, то каждый DbContext будет создавать код в файлах миграций для любых изменений, вносимых в эту сущность. В результате возникает проблема, потому что второй сценарий миграции потерпит неудачу, если изменения уже внесены в базу данных. До выхода версии EF Core 5 единственным решением было ручное редактирование одного из файлов миграций с целью удаления таких изменений.
В версии EF Core 5 производный от DbContext класс может помечать сущность как исключенную из миграций, позволяя другому DbContext становиться системой записи для данной сущности. В следующем коде сущность исключается из миграций:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity
t => t.ExcludeFromMigrations);
}
Команда remove применяется для удаления миграций из проекта и всегда работает с последней миграцией (основываясь на отметках времени миграций). При удалении миграции исполняющая среда EF Core проверяет, не была ли миграция применена к базе данных, с помощью таблицы __EFMigrationsHistory. Если миграция применялась, тогда процесс терпит неудачу. Если же миграция не применялась или была подвергнута откату, то она удаляется, а файл моментального снимка модели обновляется.
Команда remove не принимает какие-либо параметры (поскольку всегда работает с последней миграцией) и использует те же самые параметры, что и команда add, плюс дополнительный параметр force(—f || --force), который обеспечивает выполнение отката последней миграции и ее удаление за один шаг.
Команда list позволяет получить все миграции для класса, производного от DbContext. По умолчанию она выводит список всех миграций и запрашивает базу данных с целью выяснения, были ли они применены. Если миграции не применялись, то они будут помечены как ожидающие. Один из параметров команды list предназначен для передачи специальной строки подключения, а другой позволяет вообще не подключаться к базе данных и просто вывести список миграций (табл. 22.12).
Команда script создает сценарий SQL на основе одной или большего количества миграций и принимает два необязательных параметра, которые указывают, с какой миграции начинать и на какой миграции заканчивать. Если ни один параметр не задан, то сценарий создается для всех миграций. Параметры описаны в табл. 22.13.
