Отменить миграцию инфраструктуры сущностей

Обновлено: 29.06.2024

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

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

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

  1. Enable-Migrations: включает миграцию в вашем проекте путем создания класса конфигурации.
  2. Add-Migration: создает новый класс миграции в соответствии с указанным именем с помощью методов Up() и Down().
  3. Update-Database: выполняет последний файл миграции, созданный командой Add-Migration, и применяет изменения к схеме базы данных.

Чтобы использовать миграцию на основе кода, сначала выполните команду enable-migrations в консоли диспетчера пакетов. Откройте консоль диспетчера пакетов, выбрав Инструменты → Диспетчер пакетов библиотек → Консоль диспетчера пакетов, а затем запустите команду enable-migrations (убедитесь, что проектом по умолчанию является проект, в котором находится ваш контекстный класс).

сначала миграция на основе кода в коде

Команда Enable-Migrations создаст класс Configuration, производный от DbMigrationsConfiguration, с AutomaticMigrationsEnabled = false .

Теперь вам нужно установить инициализатор базы данных MigrateDatabaseToLatestVersion в вашем классе контекста, как показано ниже.

Теперь вам нужно создать класс миграции с помощью команды Add-Migration с именем вашего класса миграции, как показано ниже.

сначала миграция на основе кода в коде

Приведенная выше команда создаст файл _SchoolDB-v1.cs с методами Up() и Down(), как показано ниже.

сначала миграция на основе кода в коде

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

Чтобы узнать больше о параметрах команды add-migration, выполните команды get-help add-migration или get-help add-migration -detailed в PMC, как показано ниже.

После создания файла миграции с помощью команды add-migration необходимо обновить базу данных. Выполните команду Update-Database, чтобы создать или изменить схему базы данных. Используйте параметр –verbose для просмотра операторов SQL, применяемых к целевой базе данных.

миграция на основе кода сначала в коде
< /p>

Выполните команду get-help update-database или get-help update-database -detailed в PMC, чтобы узнать больше об этой команде.

На этом этапе база данных будет создана или обновлена. Теперь при каждом изменении классов домена выполняйте команду Add-Migration с параметром name, чтобы создать новый файл миграции, а затем выполняйте команду Update-Database, чтобы применить изменения к схеме базы данных.

Откат миграции

Предположим, вы хотите откатить схему базы данных до любого из предыдущих состояний, тогда вы можете выполнить команду update-database с параметром –TargetMigration до точки, к которой вы хотите откатиться. Например, предположим, что к вышеуказанной базе данных SchoolDB применено много миграций, но вы хотите вернуться к первой миграции. Затем выполните следующую команду.

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

Добавить миграцию

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

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

В ваш проект в каталог 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.

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

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

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

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

Удалить миграцию

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

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

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

Список переносов

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

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

Сброс всех переносов

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

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

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

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



Как выполнить метод Down MyLastMigration?

Заранее спасибо

Самые быстрые расширения Entity Framework

Принятый ответ

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

Параметр SourceMigration в вашем случае является необязательным, так как вы не применяли миграцию после MyLastMigration .

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

Редактировать: как говорит в комментариях Иван Стоев, параметр SourceMigration можно включать только вместе с параметром Script , поэтому в данном сценарии это не имеет смысла. Правильная команда будет такой:

Похожие вопросы

Entity Framework: использование транзакций и откатов. Возможно?

Проблема: (с Sql 2005). Как я могу запросить базу данных во время транзакции? (Поскольку он блокирует таблицу). Как заставить транзакцию откатиться, а затем закрыться, чтобы можно было запросить таблицу. Так что я нашел это много. [TestMethod] public void CreateUser() < TransactionScope transactionScope = new TransactionScope(); ДатаКон.

Как откатить транзакцию в Entity Framework

Я считаю (но я не являюсь экспертом в области EF), что до тех пор, пока вызов context.SaveChanges не пройдет, транзакция не будет запущена. Я ожидаю, что исключение из этого вызова автоматически отменит любую начатую транзакцию. Альтернативы (на случай, если вы хотите контролировать транзакцию) [от . «Структура программирования объектов» Дж. Лермана.

Миграции Entity Framework — включите автоматическую миграцию вместе с добавленной миграцией

Вам необходимо передать конфигурацию, для которой AutomaticMigrationsEnabled имеет значение true в конструкторе. Что-то вроде этого должно помочь. Database.SetInitializer(новый MigrateDatabaseToLatestVersion()); . с MyConfiguration что-то вроде. открытый класс MyConfiguration: Core.Migrations.Configuration < pu.

Моя проблема в том, что файл . сделка. не работает должным образом, он не должен сохранять данные для одной таблицы, если во время . трассировка. Когда вся таблица верна, только сохраните данные. Рассмотрим следующее. databaseEntites objEntites = ноль; используя (objEntites = new databaseEntites()) < objEntites.Connection.Ope.

Entity Framework – Миграции – Code First — Заполнение для каждой миграции

Когда у меня есть фиксированные данные, которые я хочу вставить с помощью миграции, я помещаю вставки непосредственно в миграцию Up(), используя вызовы . Sql("Вставить."). См. примечание в середине этой страницы: . как вставить фиксированные данные. Вы предотвращаете дублирование в методе Seed, вызывая перегрузку AddOrUpdate, которая принимает выражение идентификатора, указывающее na.

Соединение закрыто при выполнении отката транзакции в Mysql с Entity Framework 6 и поставщиком Devart

Исправлена ​​ошибка, связанная с ошибкой «Соединение должно быть открыто» при откате транзакции, если соединение уже было закрыто. Выпущена новая версия dotConnect для MySQL 8.1. Его можно скачать с . здесь. (пробная версия) или из области зарегистрированных пользователей (только для пользователей с активной подпиской). Для получения дополнительной информации, пожалуйста.

Откат транзакции Entity Framework 6

Вам не нужно звонить . Откат. вручную, потому что вы используете . с использованием. утверждение. . DbContextTransaction.Dispose. метод будет вызываться в конце файла . с использованием. блокировать. И он автоматически откатит транзакцию, если транзакция не будет успешно зафиксирована (не вызвана или не встретится с исключениями). Далее следует су.

Откат Entity Framework и удаление ошибочной миграции

Я пишу модульные тесты для тестирования фреймворка. Модульный тест добавляет и изменяет данные в существующей базе данных. Мне нужно отменить все изменения, внесенные в базу данных после завершения теста, т.е. удалить добавленные строки и вернуть измененные строки. Я использую Entity Framework 6 для доступа к базе данных. Базовой базой данных является SQL Server.

Откатить добавление/удаление в DBSets DbContext с помощью транзакции в Entity Framework

Общая схема для меня в проекте, использующем Entity Framework 6, такова: . Создайте новые объекты для добавления. Добавьте объекты в соответствующие файлы . DBSet. принадлежащий . ДбКонтекст. Задайте свойства этих объектов. Вызов . Дбконтекст.Сохранить изменения(). Вот некоторый псевдокод того, что я имею в виду. // Псевдокод для иллюстрации процесса. отменить AddProce.

Миграция — это способ синхронизации схемы базы данных с моделью EF Core путем сохранения данных.

EF Core Migration

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

Миграции EF Core — это набор команд, которые можно выполнять в консоли диспетчера пакетов NuGet или в интерфейсе командной строки dotnet.

В следующей таблице перечислены важные команды миграции в EF Core.

Команда PMC Команда CLI dotnet Использование
add-migration Добавить Создает миграцию, добавляя снимок миграции.
Удалить-миграция Удалить Удаляет последний моментальный снимок миграции.
Update-database Update Обновляет схему базы данных на основе последнего моментального снимка миграции.
Скрипт-миграция Сценарий Создает сценарий SQL, используя все снимки миграции.

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

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

Откройте консоль диспетчера пакетов в меню Сервис -> Диспетчер пакетов NuGet -> Консоль диспетчера пакетов в Visual Studio и выполните следующую команду, чтобы добавить миграцию.

Если вы используете интерфейс командной строки dotnet, выполните следующую команду.

В приведенных выше командах MyFirstMigration — это имя миграции. Это создаст три файла в папке Migrations вашего проекта, как показано ниже.

  1. _.cs: основной файл миграции, который включает операции миграции в методах Up() и Down(). Метод Up() включает код для создания объектов БД, а метод Down() включает код для удаления объектов БД.
  2. _.Designer.cs: файл метаданных миграции, содержащий информацию, используемую EF Core.
  3. ModelSnapshot.cs: снимок текущей модели. Это используется для определения того, что изменилось при создании следующей миграции.

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

Создание или обновление базы данных

Используйте следующую команду для создания или обновления схемы базы данных.

Команда Update создаст базу данных на основе классов контекста и домена, а также моментального снимка миграции, созданного с помощью команды add-migration или add.

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


Удаление переноса

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

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

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

Отмена переноса

Предположим, вы изменили класс своего домена и создали вторую миграцию с именем MySecondMigration с помощью команды add-migration и применили эту миграцию к базе данных с помощью команды Update. Но по какой-то причине вы хотите вернуть базу данных в предыдущее состояние. В этом случае используйте команду update-database, чтобы вернуть базу данных к указанному предыдущему моментальному снимку миграции.

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

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

Создание сценария SQL

Используйте следующую команду для создания сценария SQL для базы данных.

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


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

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

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

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

Давайте посмотрим, как создавать сценарии SQL для миграции

Создание сценариев SQL для применения миграций

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

  • Миграция from должна быть последней миграцией, примененной к базе данных перед запуском скрипта. Если переносы не применялись, укажите 0 (значение по умолчанию).
  • Миграция в — это последняя миграция, которая будет применена к базе данных после запуска скрипта. По умолчанию используется последняя миграция в вашем проекте.

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

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

Создание SQL-скриптов отката для ваших миграций

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

Сценарии отката можно создавать с помощью команды создания сценариев ef core. Единственная разница будет заключаться в том, что миграция "от" и "к" будет инвертирована.

Если ваша команда, которая генерирует SQL-скрипт для применения миграции, выглядит так, как показано ниже

тогда команда для создания сценария отката SQL будет выглядеть так:

Если вы хотите откатить все миграции, вы можете указать 0 в аргументе to, и аргумент from будет содержать миграцию, с которой вы хотите запустить сценарий отката.

Идемпотентные сценарии SQL

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

Следующее генерирует идемпотентные миграции:

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

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

Итак, мы увидели, как можно создавать сценарии SQL и сценарии отката для миграции EF Core.

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