Схема БД конфигурируемая (сейчас «dkb» зашита в коде и миграциях) #38

New Issue

aep · 2026-10-07T13:14:02+03:00

aep commented

2026-10-07 13:14:02 +03:00

Проблема

Имя схемы PostgreSQL dkb зашито в восьми местах:

api/src/models/base.py:10 — SCHEMA = "dkb" (MetaData моделей, sequence, enum);
api/src/db/db.py:10 — search_path: "dkb" движка приложения;
api/alembic/env.py:23 — SCHEMA = "dkb" (CREATE SCHEMA, version_table_schema);
api/alembic/versions/0001…0004 — свой SCHEMA = "dkb" в каждой миграции плюс строковые FK "dkb.app_user.id" и т.п. (0001, 0002);
api/tests/conftest.py:100 — search_path: "dkb".

Платформа может выдать БД с другой схемой (или требовать отдельную схему на стенд), а миграции сейчас пишут только в dkb.

Что сделать

Один источник: настройка (raisa_config.yml / env, например DATABASE.SCHEMA, по умолчанию dkb).
models/base.py, db/db.py (search_path), alembic/env.py читают её.
Миграции не держат свою константу: схема берётся из контекста alembic (op.get_context().version_table_schema или общий хелпер), строковые FK dkb.x.id → f"{SCHEMA}.x.id". При значении по умолчанию DDL миграций не меняется — проверить сравнением alembic upgrade --sql до/после.
Тесты: conftest.py берёт ту же настройку; тест, что миграции применяются и откатываются в схему с нестандартным именем.
README / docs/dev: как задать схему.

Почему не сейчас

Идёт Срез 3b (#36, worktree .wt/slice-3b), он трогает модели и conftest. Начинать после слияния 3b, чтобы не конфликтовать. Если 3b добавит миграцию 0005 — она тоже попадает под п. 3.

Bounded-задача (без OpenSpec change).

## Проблема Имя схемы PostgreSQL `dkb` зашито в восьми местах: - `api/src/models/base.py:10` — `SCHEMA = "dkb"` (MetaData моделей, sequence, enum); - `api/src/db/db.py:10` — `search_path: "dkb"` движка приложения; - `api/alembic/env.py:23` — `SCHEMA = "dkb"` (CREATE SCHEMA, `version_table_schema`); - `api/alembic/versions/0001…0004` — свой `SCHEMA = "dkb"` в каждой миграции **плюс** строковые FK `"dkb.app_user.id"` и т.п. (0001, 0002); - `api/tests/conftest.py:100` — `search_path: "dkb"`. Платформа может выдать БД с другой схемой (или требовать отдельную схему на стенд), а миграции сейчас пишут только в `dkb`. ## Что сделать 1. Один источник: настройка (`raisa_config.yml` / env, например `DATABASE.SCHEMA`, по умолчанию `dkb`). 2. `models/base.py`, `db/db.py` (`search_path`), `alembic/env.py` читают её. 3. Миграции не держат свою константу: схема берётся из контекста alembic (`op.get_context().version_table_schema` или общий хелпер), строковые FK `dkb.x.id` → `f"{SCHEMA}.x.id"`. При значении по умолчанию DDL миграций не меняется — проверить сравнением `alembic upgrade --sql` до/после. 4. Тесты: `conftest.py` берёт ту же настройку; тест, что миграции применяются и откатываются в схему с нестандартным именем. 5. README / docs/dev: как задать схему. ## Почему не сейчас Идёт Срез 3b (#36, worktree `.wt/slice-3b`), он трогает модели и conftest. Начинать после слияния 3b, чтобы не конфликтовать. Если 3b добавит миграцию 0005 — она тоже попадает под п. 3. Bounded-задача (без OpenSpec change).

aep referenced this issue from a commit

2026-10-07 18:26:41 +03:00

Схема БД конфигурируемая: настройка DB_SCHEMA вместо зашитой dkb (#38)

aep referenced a pull request that will close this issue

2026-10-07 18:26:56 +03:00

Схема БД конфигурируемая: DB_SCHEMA (#38) #53

aep closed this issue

2026-10-07 18:33:46 +03:00

aep referenced this issue from a commit

2026-10-07 18:33:46 +03:00

Merge pull request 'Схема БД конфигурируемая: DB_SCHEMA (#38)' (#53) from feat/38-db-schema-setting into main

aep referenced this issue