# Переход с 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`, коммит будет создан после этой записи.