Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен
Шрифт:
Интервал:
Закладка:
Команда add требует передачи параметра name, который используется при именовании созданного класса и файлов для миграции. В дополнение к общим параметрам параметр -о <путь> или --output-dir <путь> указывает, куда должны помещаться файлы миграции. Стандартный каталог называется Migrations и относителен к текущему пути.
Для каждой добавленной миграции создаются два файла с частичными определениями того же самого класса. Имена обоих файлов начинаются с отметки времени и наименования миграции, которое было указано в качестве параметра для команды add. Первый файл называется <ГГГГММДДЧЧММСС>_<НаименованиеМиграции>.cs, а второй — <ГГГГММДДЧЧММСС>_<НаименованиеМиграции>.Designer.cs. Отметка времени основана на том, когда файл был создан, и в точности совпадает для обоих файлов. Первый файл представляет код, сгенерированный для изменений базы данных в этой миграции, а конструирующий файл — код, который предназначен для создания и обновления базы данных на основе всех миграций до этой миграции включительно.
Главный файл содержит два метода, Up() и Down(). В методе Up() находится код для обновления базы данных с учетом изменений этой миграции. В методе Down() содержится код для выполнения отката изменений этой миграции. Ниже приведен неполный листинг начальной миграции, рассматриваемой ранее в главе (One2Many):
public partial class One2Many : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.CreateTable(
name: "Make",
columns: table => new
{
Id = table.Column<int>(type: "int", nullable: false)
.Annotation("SqlServer:Identity", "1, 1"),
Name = table.Column<string>(type: "nvarchar(max)", nullable: true),
TimeStamp = table.Column<byte[]>(type: "varbinary(max)",
nullable: true)
},
constraints: table =>
{
table.PrimaryKey("PK_Make", x => x.Id);
});
...
migrationBuilder.CreateIndex(
name: "IX_Cars_MakeId",
table: "Cars",
column: "MakeId");
}
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<LogEntry>().ToTable("Logs",
t => t.ExcludeFromMigrations());
}
Команда remove
Команда remove применяется для удаления миграций из проекта и всегда работает с последней миграцией (основываясь на отметках времени миграций). При удалении миграции исполняющая среда EF Core проверяет, не была ли миграция применена к базе данных, с помощью таблицы __EFMigrationsHistory. Если миграция применялась, тогда процесс терпит неудачу. Если же миграция не применялась или была подвергнута откату, то она удаляется, а файл моментального снимка модели обновляется.
Команда remove не принимает какие-либо параметры (поскольку всегда работает с последней миграцией) и использует те же самые параметры, что и команда add, плюс дополнительный параметр force(—f || --force), который обеспечивает выполнение отката последней миграции и ее удаление за один шаг.
Команда list
Команда list позволяет получить все миграции для класса, производного от DbContext. По умолчанию она выводит список всех миграций и запрашивает базу данных с целью выяснения, были ли они применены. Если миграции не применялись, то они будут помечены как ожидающие. Один из параметров команды list предназначен для передачи специальной строки подключения, а другой позволяет вообще не подключаться к базе данных и просто вывести список миграций (табл. 22.12).
Команда script
Команда script создает сценарий SQL на основе одной или большего количества миграций и принимает два необязательных параметра, которые указывают, с какой миграции начинать и на какой миграции заканчивать. Если ни один параметр не задан, то сценарий создается для всех миграций. Параметры описаны в табл. 22.13.
Если миграции не указаны, тогда созданный сценарий станет совокупным итогом всех миграций. В случае предоставления миграций сценарий будет содержать изменения между двумя миграциями (включительно). Каждая миграция помещается внутрь транзакции. Если в базе данных, где запускается команда script, таблица __EFMigrationsHistory нe существует, то она создается. Кроме того, она будет обновляться для соответствия выполненным миграциям. Вот несколько примеров: