Автоматическая code first migrations-ef6

Необходимо учитывать следующие моменты:

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

Значения по умолчанию или вычисляемые имена не могут соответствовать существующей схеме

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

Ниже приведены некоторые примеры того, когда необходимо помнить об этом.

Если вы использовали параметр «вариант 1: использовать существующую схему в качестве начальной точки» из шага 3:

Если будущие изменения в модели требуют изменения или удаления одного из объектов базы данных, названных по-другому, необходимо изменить шаблонную миграцию, указав правильное имя. API-интерфейсы миграции имеют необязательный параметр name, позволяющий сделать это.
Например, существующая схема может содержать таблицу Post со столбцом внешнего ключа Блогид, имеющего индекс с именем IndexFk_BlogId. Однако миграция по умолчанию предполагает, что этот индекс будет называться IX_BlogId. При внесении изменений в модель, которая приведет к удалению этого индекса, необходимо будет изменить сформированный вызов событие DropIndex, указав имя IndexFk_BlogId.

Если вы использовали команду «параметр 2: использовать пустую базу данных как начальную точку» из шага 3:

Попытка запустить метод down первоначальной миграции (то есть возврат к пустой базе данных) в локальной базе данных может завершиться неудачей, так как при миграции будет предпринята попытка удалить индексы и ограничения внешнего ключа с использованием неверных имен. Это повлияет только на локальную базу данных, так как другие базы данных будут создаваться с нуля с помощью метода первоначальной миграции.
Если вы хотите понизить уровень существующей локальной базы данных до пустого состояния, проще всего сделать это вручную, удалив базу данных или удалив все таблицы. После первоначального перехода все объекты базы данных будут созданы заново с именами по умолчанию, поэтому эта проблема не будет представлена повторно.
Если будущие изменения в модели нуждаются в изменении или удалении одного из объектов базы данных, названных по-другому, это не будет работать для существующей локальной базы данных, так как имена не будут соответствовать значениям по умолчанию. Однако он будет работать с базами данных, созданными «с нуля», так как они будут использовать имена по умолчанию, выбранные при миграции.
Можно либо вручную внести эти изменения в локальную существующую базу данных, либо рассмотреть возможность повторного создания базы данных с нуля, так как она будет создана на других компьютерах.
Базы данных, созданные с помощью метода up начальной миграции, могут немного отличаться от локальной базы данных, так как будут использоваться вычисляемые имена по умолчанию для индексов и ограничения внешнего ключа. Кроме того, можно получить дополнительные индексы, так как миграция будет создавать индексы внешних ключевых столбцов по умолчанию — это может быть не так в исходной локальной базе данных.

Не все объекты базы данных представлены в модели

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

Ниже приведены некоторые примеры того, когда необходимо помнить об этом.

Независимо от варианта, выбранного на шаге 3, если будущие изменения в модели нуждаются в изменении или удалении этих дополнительных объектов, миграция не будет затруднить внесение этих изменений. Например, если удалить столбец с дополнительным индексом, то при миграции не будет известно, что он удаляет индекс. Его необходимо будет добавить в шаблон миграции вручную.
При использовании параметра «вариант 2: использовать пустую базу данных в качестве начальной точки» эти дополнительные объекты не будут созданы методом первоначальной миграции.
При необходимости вы можете изменить методы up и Down, чтобы позаботиться об этих дополнительных объектах. для объектов, которые изначально не поддерживаются в API-интерфейсе миграции (например, представления), можно использовать метод Sql для запуска необработанных SQL для их создания или удаления.

Сравнение SQL и NoSQL

Если SQL-системы основаны исключительно на строгом представлении данных, то NoSQL-системы предоставляют свободу и способны работать с любым типом данных.
SQL-системы стандартизированы, за счёт чего запросы формируются с использованием языка SQL. В то же время NoSQL-системы базируются на специфической для каждой из них технологии, что является недостатком.
Масштабируемость. Обе СУБД способны обеспечить вертикальное масштабирование, то есть увеличить объём системных ресурсов на обработку данных. При этом NoSQL, будучи более новой разновидностью баз данных, позволяет применять простые методы горизонтального масштабирования.
В плане надёжности SQL обладает уверенным лидерством.
У SQL-баз есть качественная техническая поддержка за счёт их продолжительной истории, в то время как NoSQL-системы весьма молоды и и решить какую-либо проблему сложнее.
Хранение данных и доступ к их структурам в рамках реляционных систем лучше всего происходит в SQL-системах.

Таким образом, хоть NoSQL и является стремительно развивающейся разновидностью систем управления базами данных, однако на данном этапе рекомендуется остановить свой выбор на SQL.

Надёжность SQL-систем, особенно MySQL, подтверждается временем и массовостью. Сегодня любой уважающий себя ресурс использует для хранения данных именно систему MySQL.

Шаг 3. добавление начальной миграции

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

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

Вариант 1. использование существующей схемы в качестве отправной точки

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

выполните команду Add-Migration InitialCreate – игноречанжес в консоли диспетчер пакетов. При этом создается пустой перенос с текущей моделью в виде моментального снимка.
выполните команду обновления базы данных в консоли диспетчер пакетов. Это приведет к применению InitialCreate миграции к базе данных. Поскольку фактическая миграция не содержит каких-либо изменений, она просто добавляет в таблицу __MigrationsHistory строку, указывающую на то, что эта миграция уже применена.

Вариант 2. используйте пустую базу данных в качестве отправной точки

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

выполните команду Add-Migration InitialCreate в консоли диспетчер пакетов. Будет создана миграция для создания существующей схемы.
Закомментируйте весь код в методе up созданной миграции. Это позволит нам применить миграцию к локальной базе данных, не пытаясь повторно создавать все таблицы и т. д., которые уже существуют.
выполните команду обновления базы данных в консоли диспетчер пакетов. Это приведет к применению InitialCreate миграции к базе данных. Поскольку фактическая миграция не содержит каких-либо изменений (так как мы временно закомментируем их), она просто добавляет в __MigrationsHistory таблицу строку, указывающую на то, что эта миграция уже применена.
Отмена комментария к коду в методе up. Это означает, что если миграция применяется к будущим базам данных, то схема, которая уже существовала в локальной базе данных, будет создана при миграции.

Создание и применение миграций в EF Core

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

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

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

Начиная с ASP.NET Core 3.0 инструменты EF Core, необходимые для миграции, не устанавливаются предварительно. Следовательно, мы должны установить библиотеку . Если вы следите за этой серией с самого начала, значит, у вас уже установлена библиотека .

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

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

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

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

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

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

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

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

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

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

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

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

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

Update-Database

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

dotnet ef database update

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

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

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

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

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

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

Проверка работы расширений после обновлений

Иногда бывает, что после обновления конфигурации некоторые расширения перестают работать и часто такие ошибки выявляются только в процессе тестирования или рабочем режиме.
При правильной разработке и проектировании расширения можно свести к минимуму такие ошибки, но иногда их не избежать.
Если в базе расширений не более 5-10, то проверить каждое после обновления не составляет труда, а вот если их больше 50 — проверка отнимает слишком много времени
Поэтому была написана обработка, которая в автоматическом режиме проверяет расширения, подключенные в программе.
Обработка универсальная и будет работать в любой программе, в которой есть расширения.

3 стартмани

Основные сведения о принципах работы миграции

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

Первая миграция

при добавлении первой миграции в проект в консоли диспетчер пакетов запускается нечто вроде add-migration . Ниже показаны действия высокого уровня, выполняемые этой командой.

Текущая модель вычисляется из кода (1). Объекты базы данных, которые затем рассчитываются моделью, отличаются (2) — поскольку это первая миграция, то модель отличается только пустой моделью для сравнения. необходимые изменения передаются генератору кода для создания необходимого кода миграции (3), который затем добавляется в Visual Studio решение (4).

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

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

Последующие миграции

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

Как и в последнем времени, текущая модель вычисляется по коду (1). Однако на этот раз существуют миграция, поэтому Предыдущая модель извлекается из последней миграции (2). Эти две модели различны для поиска необходимых изменений базы данных (3), после чего процесс завершается как раньше.

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

Зачем нужна моментальный снимок модели?

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

Существует ряд причин, по которым EF сохраняет моментальный снимок модели:

Это позволяет базе данных отменять модель EF. Эти изменения можно вносить непосредственно в базу данных, или же можно изменить сформированный код в миграции, чтобы внести изменения. Вот несколько примеров этого на практике.
- Необходимо добавить столбец inserted и updated в одну или несколько таблиц, но не нужно включать эти столбцы в модель EF. Если миграция выполнялась в базе данных, она будет непрерывно пытаться удалить эти столбцы при каждом формировании процесса миграции. При использовании моментального снимка модели EF будет только обнаруживать допустимые изменения модели.
- Необходимо изменить текст хранимой процедуры, используемой для обновления, чтобы включить некоторые журналы. Если миграции Просмотрели эту хранимую процедуру из базы данных, она будет постоянно пытаться вернуться к определению, которое предполагается EF. С помощью моментального снимка модели EF будет только код формирования кода для изменения хранимой процедуры при изменении формы процедуры в модели EF.
- Эти же принципы применяются для добавления дополнительных индексов, включая дополнительные таблицы в базе данных, сопоставления EF с представлением базы данных, расположенным над таблицей, и т. д.
Модель EF содержит не только форму базы данных. Наличие всей модели позволяет выполнять миграцию для просмотра сведений о свойствах и классах в модели, а также о том, как они сопоставляются со столбцами и таблицами. Эти сведения обеспечивают более интеллектуальную миграцию в коде, который он формирует. Например, если изменить имя столбца, сопоставляемое свойству с миграцией, может обнаружить переименование, просматривая то же самое свойство — что не может быть выполнено, если имеется только схема базы данных.

Шаг 2. Сбор файлов и параметров с исходных компьютеров

Back up the source computer.
Закрой все приложения. Если некоторые приложения работают при запуске команды ScanState, USMT может не перенести все указанные данные. Например, если microsoft Office Outlook открыта, USMT может не перенести PST-файлы.

Примечание.
USMT не удастся, если он не сможет перенести файл или параметр, если не указать параметр /C. При указании параметра /C USMT игнорирует ошибки и регистрирует ошибку каждый раз, когда он сталкивается с файлом, который используется, который usMT не переносит. Вы можете использовать раздел ** < ErrorControl > ** в файле Config.xml, чтобы указать, какие ошибки следует игнорировать, а какие должны привести к сбой миграции.
Запустите команду ScanState на исходный компьютер для сбора файлов и параметров. Необходимо указать все .xml, которые необходимо использовать команде ScanState. Например:

Примечание.
Если исходный компьютер работает Windows 7 или Windows 8, необходимо выполнить команду ScanState в режиме администратора. Чтобы запустить в режиме администратора, щелкните правой кнопкой мыши командноеподсказок, а затем нажмите кнопку Выполнить как администратор. Если исходный компьютер Windows XP, необходимо выполнить команду ScanState из учетной записи с административными учетными данными. Дополнительные сведения о том, как команда ScanState обрабатывает и хранит данные, см. в пункте How USMT Works.
Запустите команду USMTUtils с помощью параметра /Verify, чтобы убедиться, что созданный вами магазин не поврежден.

Применение миграции во время выполнения

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

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

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

Это может быть опасно в рабочей среде.

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

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

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

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

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

Примечание

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

Начало работы

Предположим, что вы только что завершили создание первого приложения EF Core, которое содержит следующую простую модель:

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

Установка инструментов

Во-первых, необходимо установить средства командной строки EF Core:

Обычно рекомендуется использовать средства интерфейса командной строки .NET, которые работают на всех платформах.
Если вы привыкли работать в Visual Studio или знакомы с миграциями EF6, можно также использовать средства консоли диспетчера пакетов.

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

Теперь все готово к добавлению первой миграции. Укажите EF Core создать миграцию с именем InitialCreate:

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

Создание базы данных и схемы

На этом этапе в EF можно создать базу данных и схему из миграции. Это можно сделать с помощью следующих средств:

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

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

на странице применения миграций.

Развитие модели

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

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

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

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

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

Теперь можно применить миграцию, как и раньше:

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

Исключение частей модели

Примечание

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

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

Следующие шаги

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