Переход с SQLite на PostgreSQL

Зачем

Переход runtime-сервера на PostgreSQL уже выполнен, но после него остались хвосты в документации, именах, комментариях и части прямых SQL-запросов.

Этот TODO теперь нужен не для самого перехода, а для доведения проекта до полностью консистентного состояния после ухода от SQLite.

Что сделать

Дочистить документацию, где ещё описан SQLite как текущий runtime.
Убрать или переименовать legacy-названия и комментарии, которые уже не соответствуют PostgreSQL runtime.
Постепенно перенести оставшиеся прямые SQL-запросы из хэндлеров в DAO/service.
Проверить case-insensitive сравнения, уникальные ограничения и индексы уже в чисто PostgreSQL модели.
Отдельно пройтись по TODO/служебным документам и убрать ссылки на удалённые SQLite-классы как на актуальный код.

Что уже есть в коде

Доступ к БД в основном проходит через DAO-слой, а не полностью размазан по проекту.
Основная серверная логика уже разделена по модулям.
Runtime-сервер уже работает только с PostgreSQL.
Пустая БД инициализируется автоматически через schema_v1.

Откуда продолжать

Продолжать с зачистки legacy-документации и комментариев.
Затем добрать оставшиеся прямые SQL-запросы вне DAO.
После этого можно отдельно решать вопрос косметического переименования *V2, DbController и других переходных сущностей.

Что потом обновить

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

Что временно отключено и что вернуть потом

В серверном runtime временно снята проверка channelName must not contain only digits в SHiNE-server/shine-server-db/src/main/java/shine/db/channels/ChannelNameRules.java.
Причина: на боевой истории уже есть блоки с числовыми именами каналов, и сервер должен уметь с нуля восстановить blockchain_state и .bch, подтягивая старые блоки от других sync-серверов.
Что осталось как текущее поведение:
- UI по-прежнему не даёт создать новый канал только из цифр;
- сервер принимает такие имена, чтобы не ломать replay старых блоков.
Что нужно сделать отдельным следующим шагом:
- вернуть серверное продуктовое правило для новых каналов;
- сделать это совместимо со старой историей, чтобы импорт/реплей существующих блоков не падал на старых числовых channel name.
Какие документы обновить при возврате:
- docs/libs/shine-server-bd/POSTGRES_RUNTIME_SCHEMA_V1.md;
- UI/серверные документы по правилам имён каналов, если появится отдельная спецификация.
С какого сценария продолжать:
- повторить cold start тест на t2: пустая PostgreSQL schema, удалённые .bch, новый запуск, ожидание полной синхронизации от t1/t3.
Последняя полная рабочая точка с этим временным компромиссом:
- ветка migration-postgres, коммит будет создан после этой записи.

4.6 KiB Raw Blame History Unescape Escape