Доброго дня.
Кажется ранее видел вопрос подобного рода на форуме, но найти не смог.
Я понимаю, что бесшовно мигрировать не выйдет никак, но какой подход вообще можно использовать? Только отрезать старое и перезапускать на новом движке?
Добрый день!
Вы про аддон BPM, который ещё на Activiti? Способов миграции готовых нет никаких, к сожалению. В кубе, как вариант, теоретически можно было попробовать параллельно иметь и BPM, и BProc подключенными к приложению. Старые процессы доживали бы на BPM, новые создавались бы на BProc. Для этого с помощью специального свойства можно поменять префикс имён таблиц БД для аддона BPM.
Дальше с кубинского BProс на Jmix BPM миграция выглядит уже более реальной.
1 симпатия
Доброго дня, Максим.
Добрался до запуска проекта и неожиданно пришлось вновь столкнуться с вопросом, но уже с другой стороны.
При запуске приложения вижу в логах следующее:
2023-05-26 16:06:05.089 INFO 28388 --- [ main] o.f.c.e.impl.db.CommonDbSchemaManager : Upgrade needed: 6210 -> 6300. Looking for schema update resource for component 'common'
2023-05-26 16:06:05.091 INFO 28388 --- [ main] o.f.c.e.impl.db.CommonDbSchemaManager : performing upgrade on common with resource org/flowable/common/db/upgrade/flowable.all.upgradestep.6210.to.6300.common.sql
...
2023-05-26 16:06:14.798 ERROR 28388 --- [ main] o.f.e.impl.cmd.ValidateV5EntitiesCmd : Found v5 process definitions that are the latest version. Enable the 'flowable5CompatibilityEnabled' property in the process engine configuration and make sure the flowable5-compatibility dependency is available on the classpath
2023-05-26 16:06:14.798 ERROR 28388 --- [ main] o.f.e.impl.cmd.ValidateV5EntitiesCmd : Found v5 process definition with id: activityApproval:1:67510, and key: activityApproval
Соответственно, таблицы ACT_RE_MODEL, ACT_RE_DEPLOYMENT и др. не пусты, т.е. произошла некая миграция или ее попытка.
Каков сейчас правильный выход из ситуации? Очистить таблицы?
Добрый день! Если вам не нужны данные из старых таблиц Activiti, то да, удаляйте их.
1 симпатия
Доброго дня.
Попробую спросить в этой же теме.
Потыкался в меню bpm и вижу, что не созданы таблицы:
BPM_USER_GROUP_ROLE, BPM_USER_GROUP, возможно еще какие-то.
В DATABASECHANGELOG: по вхождению bpm только эти скрипты.
10,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
15,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
20,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
21-mssql,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
22,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
23,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
24,migrator,com/haulmont/cuba/liquibase/changelog/004-migrate-bpm.xml
В changelog.xml проекта:
<include file="/io/jmix/bpm/liquibase/changelog.xml"/>
Добрый день!
Ну вообще переменование таблицы BPROC_USER_GROUP в BPM_USER_GROUP делается как раз в скрипте 004-migrate-bpm.xml.
Можете описать шаги, как вы запускали миграцию? Всё согласно мануалу? Т.е. у вас был кубинский проект, в котором был подключен BProc, потом вы для существующей кубинской базы поставили контекст ликвибейза в свойство jmix.liquibase.contexts = cuba и т.п. ?
Добрый.
Нет, стоял старый аддон
Вроде бы все по нему. Хотя сейчас обратил внимание на то, что свойство слегка другое установлено студией
main.liquibase.contexts=cuba
Но думаю, что дело не в этом. Как правильно сейчас будет дропнуть таблицы старого аддона и развернуть новый?
main.liquibase.contexts - правильное имя свойства. Исправим в доке.
Суть проблемы я, кажется, начинаю понимать. Этот контекст ликвибейза (cuba), если установлен, то разрешает запуск скриптов миграции кубинских аддонов в jmix. Одновременно он запрещает выполнение скриптов создания таблиц аддонов (они типа уже должны быть смигрированы из кубы).
В вашем случае сейчас получается, что аддон-то вроде как кубинский, но смигрирован с кубы он не был, а вы добавляете его потом. Но конекст cuba по прежнему стоит и скрипты создания таблиц для только что подключенного аддона BPM не выполняются. Решения быстрого сходу пока что не вижу. Надо подумать.
Да, вы все верно поняли. В сриптах:
<changeSet author="bpm" id="1" context="!cuba">
Я могу своими чейнджлогами убить все таблицы и перетащить из артефакта чейнджлоги к себе в проект, исправив контекст. Но тут я не уверен, что скриптов 001-bpm.xml и 002-bpm.xml достаточно.
Максим, доброго дня.
Решения не нашлось?
Добрый день!
Что-то 100% рабочее, к сожалению, быстро не придумалось.
А этот ваш вариант не сработал?
Ещё в качестве направления “на подумать” появилась сейчас мысль пойти по следующему пути - не ставить контекст cuba, чтобы приложение не применяло скриптов миграции а сгенерило ченджсеты для существующих таблиц как будто вы создаёте новую базу. Потом создать новую базу для Jmix приложения и там уже каким-то образом перелить нужные данные из таблиц старой кубинской БД в новую Jmix БД.