Откатить миграцию entity framework

Обновлено: 04.07.2024

Использование dotnet ef database update <previous-migration-name>

Затем попробуйте удалить последнюю миграцию.

Удаление миграции без обновления базы данных не работает, потому что вы применили изменения к базе данных.

Чтобы полностью удалить все миграции и начать все заново, выполните следующие действия:

Чтобы отменить определенную миграцию (и):

Чтобы отменить все миграции:

Чтобы удалить последнюю миграцию:

Чтобы отменить и удалить последнюю миграцию:

Вы все еще можете использовать Update-Database команда.

Однако, судя по названию вашей миграции, я предполагаю, что это первая миграция, поэтому команда может не работать. Вы должны быть в состоянии удалить запись из __MigrationHistory таблица в вашей базе данных, а затем запустите Remove-Migration команда снова. Вы также можете удалить файл миграции и просто начать заново.

Чтобы отменить последнюю примененную миграцию, вы должны (команды консоли диспетчера пакетов):

  1. Восстановить миграцию из базы данных: PM> Update-Database <prior-migration-name>
  2. Удалить файл миграции из проекта (или он будет снова применен на следующем шаге)
  3. Обновить снимок модели: PM> Remove-Migration

Вы должны удалить запись миграции '20160703192724_MyFirstMigration' из таблицы _EFMigrationsHistory.

В противном случае эта команда удалит папку "Миграция" и "Удалить миграции":

Просто вы можете настроить миграцию по значению

Тогда иди и удали его

Чтобы "отменить" самую (последнюю?) Миграцию после того, как она уже была применена к базе данных:

  1. Откройте Обозреватель объектов SQL Server (Вид -> "Обозреватель объектов SQL Server")
  2. Перейдите к базе данных, которая связана с вашим проектом, развернув маленькие треугольники в сторону.
  3. Развернуть "Таблицы"
  4. Найдите таблицу с именем "dbo._EFMigrationsHistory".
  5. Щелкните правой кнопкой мыши по нему и выберите "Просмотр данных", чтобы просмотреть записи таблицы в Visual Studio.
  6. Удалите строку, соответствующую вашей миграции, которую вы хотите удалить (скажите "да" предупреждению, если будет предложено).
  7. Запустите "dotnet ef migrations remove" снова в командном окне в каталоге, в котором находится файл project.json. Либо запустите команду "Remove-Migration" в консоли диспетчера пакетов.

Надеюсь, что это помогает и применимо к любой миграции в проекте. Я проверял это только для самой последней миграции.

В консоли диспетчера пакетов:

Чтобы отменить все миграции, которые применяются к БД, просто запустите:

За этим следует бег Remove-Migration столько раз, сколько файлов миграции отображается в каталоге миграции. Команда удаляет последнюю миграцию, а также обновляет моментальный снимок.

Чтобы удалить последнюю миграцию, которую вы применили в соответствии с документами, используйте команду:

Эта команда должна быть выполнена из командной строки разработчика ( как открыть командную строку) внутри вашего каталога решений.

Например, если ваше приложение находится внутри имени "Приложение" и находится в папке c:\Projects. Тогда ваш путь должен быть:

Не забывайте remove-Call, так как это удалит файлы миграции и обновит Snapshot-файл.

Я не понимаю, почему мы здесь путаем. Итак, я напишу четкое объяснение и то, что вы должны заметить .

Все команды будут написаны с использованием dotnet .

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

  • При удалении миграции файл удаляется из вашего проекта (что должно быть понятно всем)
  • Удаление миграции возможно только в том случае, если миграция еще не применена к базе данных.
  • Чтобы удалить последнюю созданную миграцию: cd to_your_project тогда dotnet ef migrations remove

Неприменимые миграции (откат миграции):

  • Удаляет нежелательные изменения из базы данных
  • Не удаляет файл миграции из вашего проекта, но позволяет удалить его после отмены заявки.
  • Чтобы отменить миграцию, вы можете:
    • Создать новую миграцию dotnet ef migrations add <your_changes> и примените его, рекомендованный Microsoft.
    • Или обновите свою базу данных до указанной миграции (которая в основном не применяет или отменяет невыбранные миграции) с помощью dotnet ef database update <your_migration_name_to_jump_back_to>

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

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

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

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

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

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

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

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

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

    В EF Core 5,0 можно также изменить пространство имен независимо от каталога с помощью --namespace .

    В EF Core 5,0 можно также изменить пространство имен независимо от каталога с помощью -Namespace .

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

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

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

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

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

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

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

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

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

    Произвольные изменения через необработанные SQL

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

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

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

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

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

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

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

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

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

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

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

    Список всех существующих миграций можно просмотреть следующим образом:

    Эта команда появилась в EF Core 5,0.

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

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

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

    • Удаление папки миграций
    • создать новую миграцию и создать для нее скрипт SQL
    • В базе данных удалите все строки из таблицы журнала миграции.
    • Вставка одной строки в журнал миграции для записи того, что первая миграция уже применена, так как таблицы уже есть. SQL вставки — это последняя операция в скрипте SQL, созданном ранее.

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

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


    Старт миграций при запуске приложения

    Вам знаком следующий код?

    Если да, вероятнее всего вы накатываете миграции автоматически при старте проекта. Плохо это или хорошо, можете обсудить в комментариях. Я же в свою очередь хочу предостеречь вот от чего.

    Когда вы в cmd, PS или в консоли диспетчера пакетов вызываете какую либо операцию, связанную с миграциями, эта операция включает в явном или неявном виде 2 параметра: проект и запускаемый проект. Проект - это сборка, в которую в конечном счете будут помещены миграции. А вот запускаемый проект - проект, выбранный запускаемым для данного решения (sln). При работе через консоль диспетчера пакетов вы этот параметр никогда не увидите.

    Что это означает? А то, что ваш запускаемый проект при выполнении операции с миграциями будет собран (ну об этом вы знаете) и запущен. А это, в свою очередь, означает, что помимо всяких интеграционных штук, которые неожиданно для вас могут отработать, выполнение может дойти до кода, приведенного выше. К чему это может привести? К тому, что текущая операция с миграциями накатит предыдущую созданную вами миграцию. То есть, вы создаете миграцию, тут же, замечаете, что допустили ошибку в настройке сущности, пытаетесь ее удалить через Remove-Migration, но получаете от ворот поворот, потому что в момент запуска операции удаления миграции, она накатывается на базу. Вы, конечно же, выполняете роллбэк последней миграции и затем снова вызываете Remove-Migration. Но, угадайте, что произойдет?

    Чтобы это побороть, могу подсказать 2 подхода:

    Не использовать применение миграций при запуске проекта

    Использовать в качестве запускаемого проекта для операций с миграциями отдельный консольный запускаемый проект.

    Если есть идеи лучше, пишите в комментариях. С удовольствием обсужу с вами и приму к сведению.

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

    В общем-то, удалять миграции я рекомендую только в двух случаях:

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

    Миграция еще не слита в ветку, вы создали ее локально, но она не правильная.

    Во втором случае можно удалить последнюю миграцию, использовав команду Remove-Migration. Если миграцию уже применили к базе, надо ее предварительно откатить. После выполнения Remove-Migration почистите мусор в файле проекта (csproj). Так же, если у вас всего одна миграция или несколько, но еще не закоммичены, быстрее будет откатить снапшот через Git (или вашу систему контроля версий) и удалить файлы миграций.

    В данном случае универсальным решением будет откатить базу до удаляемой миграции, удалить все миграции после проблемной (вместе с ней). Мусор в csproj файле при этом чистить не надо.

    Создание SQL миграций

    Возможно, не все знают, но на основе разработческих миграций (тех, что создаются в коде, это майки их где-то так называли) можно создать SQL скрипты. Для этого есть команда Script-Migration. С ее помощью можно создать в т. ч. идемпотентные скрипты.

    А начиная с версии EF Core 3.0 появилась команда Script-DbContext для создания миграций из контекста базы.

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

    Редактирование сущностей

    Нут тут, казалось бы, все просто. Мы меняем что-либо в сущности, создаем миграцию, радуемся результату. Вот только результат может быть неожиданным, когда вам нужно удалить одно поле и создать другое того же типа. Мигратор при этом создаст команду для переименования столбца в БД. Все данные из удаляемого столбца, соответственно, перенесутся в новый. В данном случае можно создать 2 миграции: для удаления столбца и для создания нового. После этого, чтобы не маячили 2 миграции вместо одной, можно совместить их код Up и Down и последнюю удалить.

    Заключение

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


    Использование миграции - это стандартный способ создания и обновления базы данных с помощью Entity Framework Core. Процесс миграции состоит из двух этапов: создание миграции и применение миграции. Как мы уже говорили, схема нашей базы данных должна быть согласована с моделью базы данных, и каждое изменение в модели базы данных необходимо переносить в саму базу данных.

    Эти изменения могут быть, например, следующими:

    • Изменения в свойствах класса модели
    • Изменения конфигурации
    • Добавление или удаление свойств DbSet<T> из класса контекста

    Чтобы создать миграцию, мы можем использовать окно консоли диспетчера пакетов Visual Studio или командное окно (командная строка Windows) :

    Добавление миграции Add-Migration MigrationName [options]

    Или через интерфейс командной строки dotnet:

    dotnet ef migrations добавить MigrationName [options]

    В нашем приложении мы собираемся использовать Консоль диспетчера пакетов (PMC), поэтому давайте сделаем это, набрав:

    PM> Add-Migration InitialMigration

    После того, как мы нажмем клавишу Enter, наша миграция будет завершена.

    Действия, которые происходят за кулисами


    Файл ApplicationContextModelSnapshot.cs содержит модель базы данных и обновляется каждый раз при добавлении новой миграции. Два других файла: InitialMigration и InitialMigration.Designer - это файлы, содержащие и описывающие вновь созданную миграцию.

    Итак, если вы выполнили все шаги из предыдущих статей, содержимое файла InitialMigration должно выглядеть следующим образом:

    В этом файле есть два метода с удобными названиями Up и Down . Метод Up состоит из команд, которые будут выполнены, когда мы применим эту миграцию. В качестве противоположного действия метод Down будет выполнять команды, когда мы откатываем эту миграцию (в этом случае он просто удалит созданную таблицу).

    Применение созданной миграции

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

    Для консоли диспетчера пакетов команда:

    Update-Database [options]

    Для окна командной строки команда:

    dotnet ef database update [options]

    Поскольку мы уже определились с PMC, давайте откроем окно PMC и выполним команду:

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


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

    Но как EF Core узнает, какую миграцию нужно применить?

    Ну, он сохраняет уникальный идентификатор в _EFMigrationsHistory , который представляет собой уникальное имя файла миграции, созданного при миграции, и никогда больше не выполняет файлы с тем же именем:


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

    Добавление собственного кода в файл миграции

    Мы уже объяснили назначение методов Up и Down в нашем файле InitialMigration . Но весь код в этих методах генерируется EF Core. При необходимости мы также можем добавить наш собственный код. Мы можем использовать параметр MigrationBuilder для доступа к широкому спектру методов, которые могут помочь нам в этом процессе. Одним из таких методов является метод Sql , который мы можем использовать для добавления желаемого пользовательского кода.

    Итак, давайте откроем класс InitialMigration и изменим его, добавив наш собственный код:

    Мы должны убедиться, что метод Sql в методе Down выполняет противоположные действия, если мы решим удалить нашу миграцию.

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

    Создание миграции, если объекты и файлы Dbcontext находятся в отдельном проекте

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

    Попробуем продемонстрировать, что мы имеем в виду.

    PM> Install-Package Microsoft.EntityFrameworkCore -Version 3.1.0

    PM> Install-Package Microsoft.EntityFrameworkCore.Relational -Version 3.1.0

    Затем нам нужно добавить ссылку на проект Entities в нашем основном проекте.


    Как только мы это сделаем, нам нужно изменить пространство имен в классах ApplicationContext и Student с EFCoreApp.Entities на просто Сущности . Кроме того, мы должны сделать то же самое для директив using в классе Startup и в всех трех файлах миграции.

    После всего этого наш проект должен успешно собраться.

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

    Теперь мы можем попробовать добавить еще одну миграцию, набрав:

    PM> Add-Migration TestMigrationFromSeparateProject

    Все, что нам нужно сделать, это изменить нашу сборку миграции, поэтому давайте сделаем именно это в классе Startup :

    Теперь мы можем снова запустить ту же команду, но на этот раз она будет выполнена успешно. Мы успешно создали нашу новую миграцию вместе с файлами миграции в папке Migrations :


    Мы видим, что в файле TestMigration нет кода в методах Up и Down , и это нормально, потому что мы не изменить что-либо, но мы выполнили требуемую задачу.

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

    Мы узнали, как создавать миграции из отдельного проекта. Но в результате мы создали пустую миграцию, которая ничего не делает в нашей базе данных. Когда мы создаем миграцию, которая нас не устраивает, мы можем легко удалить ее, набрав команду Remove-Migration [options] в окне PMC. Итак, давайте сделаем это:

    Через несколько секунд наша предыдущая миграция будет удалена:


    Отлично, теперь мы можем двигаться дальше.

    Исходные данные в Entity Framework Core

    В большинстве наших проектов мы хотим иметь некоторые исходные данные в созданной базе данных. Итак, как только мы выполним наши файлы миграции для создания и настройки базы данных, мы захотим заполнить ее некоторыми исходными данными. Это действие называется заполнением данных.

    Мы можем создать код для действия заполнения в методе OnModelCreating с помощью ModelBuilder , как мы это сделали для конфигурации Fluent API. Итак, давайте добавим несколько строк в таблицу Student :

    Итак, мы используем метод HasData , чтобы информировать EF Core о данных, которые он должен заполнить. Остальная часть кода не требует пояснений, потому что мы просто добавляем необходимые данные. Мы не используем свойство IsRegularStudent , потому что мы создали конфигурацию для этого свойства, чтобы иметь значение по умолчанию.

    Теперь мы можем создать новую миграцию:

    PM> Add-Migration SeedInitialData

    И примените его:

    Мы можем проверить нашу таблицу, чтобы проверить результат:


    Лучший способ применения конфигурации и начального числа данных

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

    EF Core предоставляет лучший способ создания конфигурации Fluent API с помощью интерфейса IEntityTypeConfiguration<T> . Используя его, мы можем разделить конфигурацию для каждой сущности на отдельный класс конфигурации.

    Итак, давайте посмотрим, как это сделать.

    В проекте Entities мы собираемся создать новую папку Configuration и внутри нового класса StudentConfiguration :

    Конечно, мы не хотим генерировать исключение (это код по умолчанию после того, как VS реализует интерфейс), поэтому давайте изменим этот метод:

    Этот код немного отличается от старого кода OnModelCreating , поскольку нам больше не нужно использовать часть .Entity<Student> . Это потому, что наш объект построителя уже имеет тип EntityTypeBuilder<Student> . Мы добавили дополнительный объект для вставки, просто чтобы было что создать миграцию.

    Все, что нам нужно сделать, это изменить метод OnModelCreating :

    Теперь мы можем добавить новую миграцию и применить ее:

    PM> Add-Migration AdditionalRowInserted


    Настройте начальную миграцию сразу после запуска приложений

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

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

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

    Что ж, мы покажем вам, как именно это сделать.

    Создание метода расширения

    Давайте создадим новый класс MigrationManager в проекте Entities . Это будет статический класс, потому что мы собираемся создать метод расширения для запуска всех миграций при запуске приложения:

    Теперь нам нужно установить библиотеку Microsoft.ASPNetCore.Hosting.Abstractions (она нужна нам для типа IHost, который мы собираемся использовать в нашем методе расширения) и добавить MigrateDatabase метод расширения для этого класса:

    Мы используем тип IHost , потому что это позволяет нам связать этот метод в файле Program.cs и, конечно же, как вы можете видеть, он нам нужен для основной логики. .

    Итак, мы создаем область службы и используем ее с ServiceProvider для получения экземпляра класса ApplicationContext . В первой статье мы обсудили свойства, содержащиеся в классе DbContext , и теперь мы используем один из них (базу данных) для вызова метода Migrate для выполнения миграции.

    Применение метода MigrateDatabase

    Следующим шагом является вызов этого метода в классе Program.cs :

    Наконец, давайте удалим таблицы Student и _EFMigrationsHistory из базы данных и удалим хранимую процедуру в папке Programmability, чтобы имитировать пустую базу данных (или просто отбросим вашу базу данных: D). Затем мы можем запустить наше приложение. Мы увидим журналы в окне консоли, которые сообщают нам, что миграции выполняются. После того, как миграции завершили свою работу, мы можем проверить базу данных, чтобы убедиться, что все таблицы и процедуры были созданы снова.

    Откат и создание сценариев миграции

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

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

    Сначала добавим в начальное число еще одну строку:

    Тогда давайте создадим:

    PM> Add-Migration RevertTestMigration

    и примените миграцию:

    В базе данных мы видим, что добавлена новая строка. Но так как мы не удовлетворены этим переносом (гипотетически), давайте вернем его:

    PM> Update-Database AdditionalRowInserted

    Миграция AdditionalRowInserted была предыдущей, и если мы проверим нашу базу данных сейчас, мы увидим, что она была возвращена к определенным значениям миграции.

    Наконец, если мы хотим создать сценарий SQL для всех наших миграций, мы можем сделать это, набрав:

    Эта команда создаст для нас файл сценария.

    Заключение

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

    Читайте также: