Какой в Jmix рекомендованный способ заполнения БД начальными данными?

Вопросы и проблемы
#1

Часто требуется, чтобы после развертывания приложения и создания его БД, часть таблиц была проинициализирована некими начальными данными.
В Cuba для этого использовали скрипт 30.create-db.sql для соответствующей СУБД.

Сейчас вроде логично использовать для этого файлы changelog Liquibase размещенные в корне liquibase/changelog/.
Но, как я понимаю, эти изменения накатываются до штатного создания таблиц сущностей приложения.
Или есть способ поигаться тегом context чтобы применить изменения после штатного создания сущностей?

Или добавлять в проект для каждой поддерживаемой СУБД соответствующий скрипт заполнения БД и самостоятельно выполнять его при пером старте приложения?

1 симпатия
#2

Путем перемещения и переименования, созданного студией файла changelog для создания сущностей проекта, получилось проинициализировать БД нужными начальными данными.
Но если есть более правильный путь решения этой задачи в Jmix – буду благодарен за совет.

#3

Можете сделать так же, как в этом сэмпле: https://github.com/jmix-projects/sample-sales-jmix

image

Скрипты, которые нужно выполнять последними, кладутся в папку “data”. Она всегда алфавитно будет позже, чем 2021, 2022, …

Но нужно учесть, что для Liquibase нет понятия “init” скриптов, есть только update-скрипты. Если добавить новый ченджсет, то он выполнится и для новых баз данных, и для ранее существовавших.

Можно попробовать поиграться со свойствами jmix.liquibase.contexts, jmix.liquibase.labels, чтобы часть ченджсетов не запускалась на сервере при последующих обновлениях БД.

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

Я бы делал не скрипт, а прямо создал бин в коде приложения, который при старте сервера сохраняет сэмпл-сущности в БД, и запоминает в какой-то табличке признак того, что база проинициализирована. Это самое лучшее решение на мой взляд, т.к. автоматически срабатывает заполнение аудит-полей, entity changed эвенты, и еще код заполнения сущностей типизированный, не будет проблем, что какой-то столбец переименовали или удалили в сущности, а init-скрипты забыли подправить.

1 симпатия
#4

Спасибо за такой подробный ответ!

Есть над чем подумать…

Про бин-инициализатор БД тоже была мысль, но у нас в одном из приложений после создания новой БД не просто несколько записей нескольких справочников заполняются.
Мы там типовой набор папок приложения вливаем, типовые отчеты с файлами их шаблонов и т.п. громоздкие данные…
Собственно, поэтому и cahgeset с тегом loadData и загрузкой из csv тоже не вариант.

На Cuba у нас для этих целей были созданы эталонные БД приложения для 2х поддерживаемых СУБД, предзаполненные однажды нужными начальными данными.
Мы просто поддерживали их в актуальном состоянии, накатывая обновления и экспортировали периодически из них данные из нужных таблиц в SQL-скрипт 30.create-db.sql.