Начните не с sqlrs, а с источника истины
Prepare-команда должна воспроизводить ту же схему и обязательные начальные данные, с которыми проект обычно начинает работу. Поэтому сначала найдите принятый в проекте источник истины, а уже затем выбирайте команду sqlrs.
| Как управляется схема | Источник prepare | Команда |
|---|---|---|
| SQL-файлы, psql-скрипты | Главный SQL-файл и подключаемые через \i/\ir файлы | prepare:psql |
| Liquibase | Корневой changelog и все подключаемые им changelog-файлы | prepare:lb |
| Flyway, ORM или собственный инструмент миграций | Детерминированный SQL, экспортированный или собранный тем же процессом | prepare:psql |
| Ручные изменения в общей базе | Сначала превратите их в версионируемый SQL или changelog | Не автоматизировать ручной процесс как есть |
В примерах ниже сначала используется прямая, или raw, форма команды: все аргументы видны в командной строке. Когда команда заработает, её можно сохранить как короткий alias и коммитить вместе с проектом.
Вариант A: raw SQL и psql
sqlrs plan:psql -- -f db/prepare.sql
sqlrs prepare:psql -- -f db/prepare.sqlСначала используйте plan:psql, чтобы проверить план и входные файлы без создания экземпляра. В результате вы увидите идентификатор итогового состояния (state ID) и упорядоченный список задач. У шага state_execute поле cached показывает, будет ли prepare выполнять этот шаг или переиспользует готовое состояние. Файлы должны находиться внутри рабочей области. Пути прямой команды считаются от текущего каталога.
DSN=postgres://…В отличие от plan, prepare создаёт изменяемый экземпляр и печатает его строку подключения в стандартный вывод (stdout). Всё после DSN= передавайте клиенту базы или приложению; значение относится только к этому экземпляру.
Вариант B: Liquibase
sqlrs plan:lb -- update --changelog-file db/changelog.xml
sqlrs prepare:lb -- update --changelog-file db/changelog.xmlLiquibase должен быть установлен на локальной машине. Если исполняемый файл не находится автоматически, укажите его в секции liquibase файла .sqlrs/config.yaml. Корневой changelog и все подключаемые файлы должны оставаться внутри рабочей области.
Формат результата такой же: plan показывает задачи и попадания в кэш, а успешный prepare заканчивается строкой DSN=postgres://… для созданного экземпляра.
Вариант C: ORM, Flyway или свой инструмент миграций
sqlrs не умеет напрямую выполнять Flyway, команды ORM или произвольный инструмент миграций во время prepare. Если запустить такой инструмент уже после prepare, он изменит только один экземпляр, а сохранённое состояние останется прежним и не будет содержать эти миграции.
Надёжный переходный путь:
- сгенерировать полный SQL тем же инструментом и версией, что использует проект;
- убедиться, что одинаковые входы дают одинаковый SQL, и положить результат в рабочую область;
- передать файл в
prepare:psql; - обновлять SQL вместе с миграциями и проверять расхождения в CI.
Сохраните команду как alias
После первого успешного запуска материализуйте репозиторный рецепт:
sqlrs alias create test-db prepare:psql -- -f db/prepare.sql
sqlrs prepare test-dbСоветПроверка и список псевдонимов
Проверить корректность псевдонима можно командой sqlrs alias check.
Посмотреть, какие псевдонимы есть в текущей рабочей области, можно командой sqlrs alias ls.
СоветОтделяйте стабильные данные от изменчивых
Схему и редко меняющиеся справочные данные полезно отделять от тестовых данных, которые меняются при каждом запуске. Команда discover --prepare-shaping может заметить некоторые смешанные каталоги по именам файлов, но не разбирает связи между файлами и не переписывает рецепт.
Команда создаст test-db.prep.s9s.yaml. Alias — это короткое имя версионируемого рецепта, а не готовая база. В отличие от прямой команды, пути внутри alias разрешаются относительно самого alias-файла. Поэтому рецепт продолжает работать из разных каталогов и в CI.