Управление миграциями

  • Статья

По мере изменения модели миграции добавляются и удаляются в рамках нормальной разработки, а файлы миграции проверка в управление версиями проекта. Чтобы управлять миграцией, необходимо сначала установить средства командной строки EF Core.

Совет

Если DbContext находится не в той же сборке, что и начальный проект, можно явным образом указать целевой и начальный проекты в средствах консоли диспетчера пакетов или в средствах .NET Core CLI.

Добавление миграции

После изменения модели можно добавить миграцию для этого изменения:

dotnet ef migrations add AddBlogCreatedTimestamp

Имя миграции можно использовать как сообщение фиксации в системе управления версиями. Например, можно выбрать имя, например AddBlogCreatedTimestamp , если изменение является новым CreatedTimestamp свойством в сущности Blog .

В каталог Migrations проекта добавляются три файла.

  • XXXXXXXXXXXXXX_AddCreatedTimestamp.cs-Основной файл миграции. Содержит операции, необходимые для применения миграции (в Up) и ее отмены (в Down).
  • XXXXXXXXXXXXXX_AddCreatedTimestamp.Designer.cs-Файл метаданных миграции. Содержит сведения, используемые EF.
  • MyContextModelSnapshot.cs — моментальный снимок текущей модели. Используется для определения появившихся изменений при добавлении следующей миграции.

Метка времени в именах файлов позволяет расположить их в хронологическом порядке, чтобы вы могли отслеживать ход изменений.

Пространства имен

Вы можете свободно перемещать файлы миграций и изменять их пространство имен вручную. Новые миграции создаются в виде элементов того же уровня, что и последняя миграция. Кроме того, можно указать каталог во время создания следующим образом:

dotnet ef migrations add InitialCreate --output-dir Your/Directory

Примечание.

Вы также можете изменить пространство имен независимо от каталога с помощью --namespace.

Настройка кода миграции

Хотя EF Core обычно создает точные миграции, следует всегда просматривать код и убедиться, что он соответствует требуемому изменению; В некоторых случаях это даже необходимо сделать.

Переименование столбцов

Один из важных примеров, когда требуется настройка миграции, заключается в переименовании свойства. Например, если переименовать свойство из NameFullName, EF Core создаст следующую миграцию:

migrationBuilder.DropColumn(
    name: "Name",
    table: "Customers");

migrationBuilder.AddColumn<string>(
    name: "FullName",
    table: "Customers",
    nullable: true);

EF Core обычно не может знать, когда намерение удалить столбец и создать новый (два отдельных изменения), а также когда столбец следует переименовать. Если приведенная выше миграция применяется как есть, все имена клиентов будут потеряны. Чтобы переименовать столбец, замените приведенную выше миграцию следующим образом:

migrationBuilder.RenameColumn(
    name: "Name",
    table: "Customers",
    newName: "FullName");

Совет

Процесс создания новой миграции предупреждает, если операция может привести к потере данных (например, содержит удаление столбца). Увидев это предупреждение, проверьте точность кода миграции с особой тщательностью.

Добавление необработанного SQL

При переименовании столбца можно добиться через встроенный API, во многих случаях это невозможно. Например, может потребоваться заменить существующие FirstName и LastName свойства одним новым FullName свойством. Миграция, созданная EF Core, будет следующей:

migrationBuilder.DropColumn(
    name: "FirstName",
    table: "Customer");

migrationBuilder.DropColumn(
    name: "LastName",
    table: "Customer");

migrationBuilder.AddColumn<string>(
    name: "FullName",
    table: "Customer",
    nullable: true);

Как и раньше, это приведет к нежелательной потере данных. Чтобы передать данные из старых столбцов, мы переупорядочением миграции и вводим необработанную операцию SQL следующим образом:

migrationBuilder.AddColumn<string>(
    name: "FullName",
    table: "Customer",
    nullable: true);

migrationBuilder.Sql(
@"
    UPDATE Customer
    SET FullName = FirstName + ' ' + LastName;
");

migrationBuilder.DropColumn(
    name: "FirstName",
    table: "Customer");

migrationBuilder.DropColumn(
    name: "LastName",
    table: "Customer");

Произвольные изменения с помощью необработанного SQL

Необработанный SQL также можно использовать для управления объектами базы данных, о которых EF Core не знает. Для этого добавьте миграцию, не изменив модель; Будет создана пустая миграция, которую можно заполнить необработанными операциями SQL.

Например, следующая миграция создает хранимую процедуру SQL Server:

migrationBuilder.Sql(
@"
    EXEC ('CREATE PROCEDURE getFullName
        @LastName nvarchar(50),
        @FirstName nvarchar(50)
    AS
        RETURN @LastName + @FirstName;')");

Совет

EXEC используется, когда инструкция должна быть первой или единственной в пакете SQL. Его также можно использовать для обхода ошибок синтаксического анализа в сценариях идемпотентной миграции, которые могут возникать, когда ссылки на столбцы в настоящее время не существуют в таблице.

Это можно использовать для управления любым аспектом базы данных, включая:

  • Хранимые процедуры
  • Компонент Full-text Search
  • Функции
  • Триггеры
  • Представления

В большинстве случаев EF Core автоматически упаковывает каждую миграцию в свою собственную транзакцию при применении миграций. К сожалению, некоторые операции миграции не могут выполняться в рамках транзакции в некоторых базах данных; в этих случаях вы можете отказаться от транзакции, передав в suppressTransaction: truemigrationBuilder.Sql.

Удаление миграции

Иногда, добавив миграцию, вы понимаем, что нужно внести дополнительные изменения в модель EF Core перед ее применением. Для удаления последней миграции используйте приведенную ниже команду.

Удалив миграцию, вы можете внести в модель дополнительные изменения и снова добавить ее.

Предупреждение

Избегайте удаления любых миграций, которые уже применены к рабочим базам данных. Это означает, что вы не сможете отменить изменения эти миграции из баз данных и могут нарушить предположения, сделанные последующими миграциями.

Перечисление миграций

Вы можете перечислить все существующие миграции следующим образом:

Проверка ожидающих изменений модели

Примечание.

Эта функция была добавлена в EF Core 8.0.

Иногда может потребоваться проверка, если с момента последней миграции произошли какие-либо изменения модели. Это поможет вам узнать, когда вы или товарищ по команде забыли добавить миграцию. Один из способов сделать это с помощью этой команды.

dotnet ef migrations has-pending-model-changes

Этот проверка также можно выполнять программными средствамиcontext.Database.HasPendingModelChanges(). Это можно использовать для записи модульного теста, который завершается сбоем при добавлении миграции.

Сброс всех миграций

В некоторых крайних случаях может потребоваться удалить все миграции и начать работу. Это можно легко сделать, удалив папку Migrations и удаляя базу данных. На этом этапе можно создать новую начальную миграцию, которая будет содержать всю текущую схему.

Можно также сбросить все миграции и создать одну, не теряя данные. Иногда это называется "скваширование", и включает в себя некоторые ручной работы:

  1. Создайте резервную копию базы данных, если что-то не так.
  2. В базе данных удалите все строки из таблицы журнала миграций (например DELETE FROM [__EFMigrationsHistory] , в SQL Server).
  3. Удалите папку Migrations .
  4. Создайте новую миграцию и создайте скрипт SQL для него (dotnet ef migrations script).
  5. Вставьте одну строку в журнал миграций, чтобы записать, что первая миграция уже применена, так как таблицы уже есть. Вставка SQL является последней операцией в скрипте SQL, созданном выше, и напоминает следующее (не забудьте обновить значения):
INSERT INTO [__EFMigrationsHistory] ([MIGRATIONID], [PRODUCTVERSION])
VALUES (N'<full_migration_timestamp_and_name>', N'<EF_version>');

Предупреждение

Любой пользовательский код миграции будет потерян при удалении папки Migrations . Любые настройки должны применяться к новой первоначальной миграции вручную, чтобы сохраниться.

Дополнительные ресурсы