Documentation
¶
Overview ¶
Package main — отдельный binary `kaname-migrator`: единая точка сборки CLI миграций (cmd-binary не смешивает обязанности). Обслуживает миграции БД сервиса kaname (схема `kaname`).
API совпадает с goose-flavour:
kaname-migrator up [--target <номер>] kaname-migrator down [--target <номер>] kaname-migrator status
Глагола `create` здесь НЕТ — и это решение, а не пропуск (kacho#566) ¶
Он был и выдавал `goose.Create` без `SetSequential`. Имя миграции в этом дереве пишет АВТОР: форма номера — решение, а инструмент принял бы его молча и всегда одинаково.
Действующая форма — метка времени заведения `YYYYMMDDHHMMSS_<что_делает>.sql` (`date -u +%Y%m%d%H%M%S`). Объявлена она в ОДНОМ месте и здесь НЕ переписывается: docs/engineering/architecture/migration-version-namespace.md. Своей редакции у справки быть не должно — две редакции об одном предмете расходятся молча, и расходились (kacho#1026).
Флаги верхнего уровня:
--dialect postgres (default; единственный поддерживаемый) --dsn <connection-string> (или ENV MIGRATOR_DSN; прежнее написание KACHO_MIGRATOR_DSN — окном общего пакета)
Источников адреса базы три — `--dsn`, переменная наката, конфигурация службы (`config.Load()`, viper: одно helm-values задаёт БД-параметры обоим binary, не дублируя DSN), — и объявленным может быть РОВНО ОДИН. Два объявленных разом — отказ, называющий каждый: то же правило, что у службы при двух её формах адреса (#532, см. resolveDSN). Старшинства между источниками нет намеренно: выбранное молча, оно накатывало схему на одну базу, пока служба того же пода читала другую.