SpringBoot (Kotlin) - запуск миграции данных за один раз в виде пакетного задания

Question

Итак, у меня есть конкретная проблема, и я не могу найти лучшую практику Spring для этого.

У меня есть экземпляр Spring перед базой данных Postgres.У меня есть объект домена, к которому я добавляю некоторые поля (используя flyway).

По существу, представьте, что у меня есть следующий объект:

Book
last_text_update // 2018-11-25 07:00:00
last_writer      // PUBLISHER
is_finished      // true
contract_closed_timestamp // NULL

Из этого мы делаем странные вычисления, такие как

"Если last_writer == ИЗДАТЕЛЬ && is_finished == true, вернуть IS_SELLING_IN_STORES"

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

Book
processedStatus: PUBLISHED/EDITING/PROPOSAL
workStatus: AWAITING_EDITOR_FEEDBACK/AWAITING_CHANGES/FINISHED
etc.etc.

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

1) Определить все переходы столбцов в необработанном SQL и выполнить эту миграцию на производственном сервере, как и любую другую миграцию.то есть where timestamp = blah and other timestamp = blah, set status as follows

2) Запустите одноразовое пакетное задание, которое циклически просматривает каждый объект и обновляет его.

Кажется, что было бы легче сделать в коде Kotlin через пакетное задание противЯ делаю это в SQL, но какой консенсус по этому поводу?Рекомендуется ли выполнять одноразовое пакетное задание (т. Е. Выполнить ssh для экземпляра и запустить его вручную, запустить его с HTTP через API и т. Д.) Или мне просто нужно сосать его и использовать SQL?

Answer 1

Миграция с использованием SQL (вариант 1) кажется более разумной, учитывая, что

1. вы уже используете Flyway и
2. Мне кажется уродливым загрязнять модель сущностей, чтобы позволить ейвыполнить миграцию данных.например,
   • вам понадобится модель сущностей, которая будет вести себя при «неполной» форме персистентности, и
   • , вам нужно сохранить устаревшие поля и т. д.

Не забывайте о разнице в производительности, если вы перебираете множество объектов.Если нет каких-либо особых требований, требующих внесения изменений с использованием объектной модели (например, отправка событий и т. Д.), Представляется более разумным выполнить миграцию данных с использованием SQL.