byrsapty
205dd5e079
netpulse-migrate замість PowerShell-скрипта: у контейнері немає ані psql, ані PowerShell, а тягнути клієнт Postgres в образ заради одного запуску — це половина дистрибутива на порожньому місці. Міграції вшиті через embed і переїхали в server/migrations: embed не бачить нічого за межами кореня свого модуля, а міграції поруч із бінарником, який їх накочує, не можуть розійтися версіями. Накочування під advisory-блокуванням: два інстанси при rolling update інакше застосували б ту саму міграцію двічі. Кожен файл в одній транзакції разом із записом у schema_migrations; виняток — continuous aggregates, які TimescaleDB забороняє в транзакції. Змінена вже застосована міграція зупиняє запуск: у різних інсталяціях інакше опиниться різна схема під одним номером. Перевірено на чистій базі: 23 міграції, 101 таблиця, повторний запуск каже «схема актуальна». Веб віддає сам API через embed: на self-hosted це прибирає з інструкції встановлення цілий компонент. Три політики кешування — назавжди для assets із хешем у імені, ніколи для index.html, коротко для решти. Знайдено живим прогоном: невідомий шлях під /api/ віддавав 200 з index.html, і клієнт падав на розборі HTML як JSON замість чесного 404. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.1 KiB
1.1 KiB
Міграції переїхали
Файли схеми тепер лежать у server/migrations/.
Причина технічна: netpulse-migrate вшиває їх у бінарник через
//go:embed, а embed не бачить нічого за межами кореня свого модуля.
Модуль сервера починається в server/, тож db/migrations для нього
недосяжні.
Це не лише про компіляцію. Міграції поруч із бінарником, який їх накочує, не можуть розійтися версіями: у контейнері немає способу підсунути схему з іншого релізу.
Накочування:
netpulse-migrate -dsn postgres://user:pass@host:5432/netpulse
netpulse-migrate -dsn … -dry-run # лише показати, що буде застосовано
Генератор профілів NCM (db/profiles/build.py) пише свій результат
туди ж — у server/migrations/0014_ncm_profiles.sql.