Сервер: дочистить PostgreSQL runtime и документацию

2026-07-27 18:01:15 +04:00
parent b5116474c7
commit 618a30c2ab
20 changed files with 47 additions and 46 deletions
@@ -49,7 +49,7 @@
 - `medium/2026-05-26_0029_esp32s3_file_storage.md` - ESP32S3 как личное файловое хранилище SHiNE для файлов переписок и вложений.
 - `medium/2026-06-02_сессионные_homeserver_в_pda.md` - несколько homeserver-ов пользователя как типизированные сессии в PDA с версией записи.
 - `medium/2026-06-03_подключение_других_устройств_через_qr.md` - довести подключение других устройств через QR: сейчас заготовка есть, но сценарий работает нестабильно и его нужно будет отдельно доделать.
- `medium/2026-07-22_переход_с_sqlite_на_postgresql.md` - подготовить перевод серверной БД с `SQLite` на `PostgreSQL` для более серьёзной конкурентной нагрузки и дальнейшего масштабирования.
+- `medium/2026-07-22_переход_с_sqlite_на_postgresql.md` - завершить зачистку хвостов после перевода серверной БД с `SQLite` на `PostgreSQL`.

 ### dao_запуск

@@ -2,32 +2,30 @@

 ## Зачем

-Текущая серверная база на `SQLite` удобна для простого односерверного режима, но она хуже подходит для большого числа параллельных записей, роста нагрузки и дальнейшего масштабирования сервера.
+Переход runtime-сервера на `PostgreSQL` уже выполнен, но после него остались хвосты в документации, именах, комментариях и части прямых SQL-запросов.

-`PostgreSQL` нужен как следующий уровень серверной БД для более надёжной конкурентной записи, более предсказуемой работы под нагрузкой и дальнейшего роста проекта.
+Этот TODO теперь нужен не для самого перехода, а для доведения проекта до полностью консистентного состояния после ухода от `SQLite`.

 ## Что сделать

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

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

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

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

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

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

@@ -11,7 +11,7 @@

 ## Что именно потом сделать

- удалить временную миграцию `migrateToV11()` из [SqliteDbController.java](/home/ai/work/SHiNE/SHiNE-server-sha256/SHiNE-server/shine-server-db/src/main/java/shine/db/SqliteDbController.java);
+- найти историческое место, где была добавлена временная миграция `migrateToV11()`, и убрать её остатки из runtime-логики/документации;
 - удалить helper `clearLegacySignedMessagesForDmV11(...)`;
 - поднять версию схемы дальше обычным образом уже без destructive-cleanup;
 - при необходимости заменить это на нормальную точечную миграцию старых DM-записей или совсем убрать поддержку старой истории.