Перенос данных Entity Framework с пользовательской логикой?
Предположим, я хочу заменить таблицу A
на таблицу B
и перенести все данные из одного в другой, поэтому я:
- Создать таблицу
B
через SQL-запрос
- Выполните преобразование всей копии данных из формата
A
в формат B
с помощью SQL-запроса
- Поместите все в таблицу
B
через SQL-запрос
- Удалить таблицу
A
через SQL-запрос
Проблема заключается в том, что иногда вам нужно разорвать транзакцию и сделать преобразование без транзакции из формата A
в формат B
, что может даже включать вызовы для разных сервисов (например, новый геополитический статус объекта из A
или другой договор сериализации полей из A
, 7zip от A
до B
или все, что вы хотите изменить о данных в A
).
Итак, вопрос в том, как сделать шаг 2 через EF в любым желаемым способом:
- Выполните преобразование всей копии данных из формата
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, так и действительно ссылаться на свои собственные классы для доступа и обработки данных и т.д.