Перенос данных Entity Framework с пользовательской логикой?

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

  • Создать таблицу B через SQL-запрос
  • Выполните преобразование всей копии данных из формата A в формат B с помощью SQL-запроса
  • Поместите все в таблицу B через SQL-запрос
  • Удалить таблицу A через SQL-запрос

Проблема заключается в том, что иногда вам нужно разорвать транзакцию и сделать преобразование без транзакции из формата A в формат B, что может даже включать вызовы для разных сервисов (например, новый геополитический статус объекта из A или другой договор сериализации полей из A, 7zip от A до B или все, что вы хотите изменить о данных в A).

Итак, вопрос в том, как сделать шаг 2 через EF в любым желаемым способом:

  1. Выполните преобразование всей копии данных из формата A в формат B через "черный ящик"

Под этим я подразумеваю, что не нарушаю концепцию файлов миграции EF и предоставляю мне что-то вроде метода "Главная" в качестве точки входа для моего этапа перехода. Любые предложения?

ОТВЕТЫ

Ответ 1

К сожалению, это невозможно с Entity Framework. Каждая операция, доступная в миграциях, преобразуется в операции SQL, которые позже вызывается. (Используя этот способ, EF позволяет script весь процесс миграции в файл SQL и запускать его, например, в SQL Server Management Studio).

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

Поскольку миграции позволяют использовать только функции, предоставляемые SQL Server (или различные БД, если они поддерживаются), вы можете использовать такие функции, как CLR Assemblies или xp_cmdshell, которые не являются самыми простыми в использовании, но в этом случае можно выполнить почти любую миграцию код

Ответ 2

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