Рекомендуемый способ очистки старых миграций Entity Framework Core

Хорошо, с тех пор как я задал этот вопрос, я немного поэкспериментировал с этим.

На данный момент кажется, что лучший способ сделать это — вариант 1. Вариант 2 был бы намного лучше, но пока не будет реализован эта функция EFCore, это не совсем выполнимо для моего варианта использования (поддержка существующих баз данных с миграциями на них и поддержка пустых баз данных) .

Вариант 1 также имеет несколько подводных камней, на которые я наткнулся (может быть, даже больше, на которые я не наткнулся). Итак, вот как я это сделал:

Создайте новую начальную миграцию:

1. Убедитесь, что все ваши существующие миграции были применены к вашей базе данных. Мы создадим новую начальную миграцию, поэтому миграции, которые не были применены, будут потеряны.
2. Удалите старые файлы миграции EFCore и файл моментального снимка базы данных.
3. Создайте новую начальную миграцию из текущего состояния вашей базы данных. (Например, через dotnet ef migrations add Initial-PostCleanup.)

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

1. Создайте сценарий SQL для новой начальной миграции через dotnet ef migrations script -o script.sql.
2. Удалите первую транзакцию (до первой GO), которая создает __EFMigrationsHistory таблицу:

IF OBJECT_ID(N'[__EFMigrationsHistory]') IS NULL
BEGIN
    CREATE TABLE [__EFMigrationsHistory] (
        [MigrationId] nvarchar(150) NOT NULL,
        [ProductVersion] nvarchar(32) NOT NULL,
        CONSTRAINT [PK___EFMigrationsHistory] PRIMARY KEY ([MigrationId])
    );
END;

GO

3. Удалите последнюю транзакцию, которая вставляет новую запись в таблицу __EFMigrationsHistory:

INSERT INTO [__EFMigrationsHistory] ([MigrationId], [ProductVersion])
VALUES (N'20190704144924_Initial-PostCleanup', N'2.2.4-servicing-10062');

GO

4. Удалите команды GO, так как мы поместим скрипт создания в оператор IF:
   Замените GO\r\n\r\n ничем.
5. Теперь откройте файл миграции (файл C#, а не файл sql) и замените метод Up следующим:

protected override void Up(MigrationBuilder migrationBuilder)
{
    migrationBuilder.Sql(@"
DECLARE @migrationsCount INT = (SELECT COUNT(*) FROM [dbo].[__EFMigrationsHistory])
IF @migrationsCount = 0
BEGIN
    % PASTE YOUR EDITED SQL SCRIPT HERE %
END
");
}

Сделанный! Теперь все должно работать!

Обязательно сравните схему базы данных, а также данные до и после новой базы данных. Все, что не является частью, если ваша модель EF Code не является частью новой базы данных.

Немного поздно, но у нас была такая же проблема в нашем текущем проекте. Более 400 миграций и 6 миллионов строк кода внутри .Designer. Вот как нам удалось решить эту проблему:

MigrationProject.csproj

  <PropertyGroup>
     ...
     <DefaultItemExcludes Condition = "'$(Configuration)' == 'Debug' ">$(DefaultItemExcludes);Migrations\**\*.Designer.cs</DefaultItemExcludes>
  </PropertyGroup>

Таким образом, вам не нужно ни сбрасывать миграцию в чистое состояние, ни удалять файлы .Designer. Вы всегда можете изменить конфигурацию на Release и использовать файлы .Designer любыми средствами.

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

(1) Убедитесь, что файл program.cs не оптимизирован для создания/обновления базы данных с помощью команды Database.EnsureCreate, так как эта команда предотвращает миграцию. (2) Удалить папку Миграции.
(3) сборка дотнета
(4) обновление базы данных dotnet ef 0 -c yourContextFile
(5) миграция dotnet ef добавляет init -c yourContextFile
(6) обновление базы данных dotnet ef -c yourContextFile