alembic/env.py регистрирует только Parcel — JobSetting и ~50 реальных таблиц невидимы для drift-detection, autogenerate сгенерировал бы фантомный CREATE TABLE parcels #1569

New issue

Closed

opened 2026-06-16 17:06:25 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-16 17:06:25 +00:00

Collaborator

Severity: medium · Категория: schema-drift/tooling-correctness · Файл: backend/alembic/env.py:11-22

backend/alembic/env.py:14 — единственный импорт моделей 'from app.models import parcel', но app/models/init.py пуст, а app/models/job_settings.py нигде не импортируется при загрузке alembic. Поэтому в target_metadata = Base.metadata (env.py:24) попадает ровно одна таблица 'parcels' (из app/models/parcel.py), которой в реальной БД нет (реальные данные в cad_parcels / cad_parcels_geom, см. data/sql/92_cad_bulk_layers.sql:51, data/sql/83_cad_parcels_geom.sql:10). Impact: docstring (env.py:1-2) обещает регистрацию всех моделей для детекции дрейфа схемы, но (a) 'alembic revision --autogenerate' эмитит op.create_table('parcels', ...) для несуществующей таблицы; (b) даёт нулевое покрытие для job_settings и остальных ~50 prod-таблиц. Латентно, т.к. versions/ пуст (миграции применяются raw SQL из data/sql/*.sql), но инструмент выглядит рабочим и активно вводит в заблуждение. Fix: либо импортировать все ORM-модели в app/models/init.py (и подтянуть его в env.py), включая JobSetting; либо, если ORM-модели не отражают реальную схему (см. parcel.py), удалить фейковый Parcel и честно задокументировать, что autogenerate здесь не используется.

Почему баг: Drift detection is the stated, sole purpose of this env.py (alembic/versions/ is empty except .gitkeep — migrations are applied via raw data/sql/*.sql). Because metadata holds only the phantom parcels table: (a) alembic revision --autogenerate generates op.create_table('parcels', ...) for a table that must never exist, and (b) it gives ZERO coverage for the tables it claims to watch, including the actively-used job_settings table. The comment 'Add new model modules here as they appear' was simply not followed for job_settings. The tooling looks like it provides drift detection but is effectively non-functional and actively misleading.

Как чинить: Either import every real model module in env.py (and have models/init.py re-export them) so Base.metadata reflects the real schema, OR — since migrations are hand-written SQL and these ORM models map to phantom/legacy tables — disable autogenerate (target_metadata = None) and drop the misleading docstring. At minimum add from app.models import job_settings # noqa: F401.

_{deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.9 · unit B07}

**Severity:** medium · **Категория:** schema-drift/tooling-correctness · **Файл:** `backend/alembic/env.py:11-22` backend/alembic/env.py:14 — единственный импорт моделей 'from app.models import parcel', но app/models/__init__.py пуст, а app/models/job_settings.py нигде не импортируется при загрузке alembic. Поэтому в target_metadata = Base.metadata (env.py:24) попадает ровно одна таблица 'parcels' (из app/models/parcel.py), которой в реальной БД нет (реальные данные в cad_parcels / cad_parcels_geom, см. data/sql/92_cad_bulk_layers.sql:51, data/sql/83_cad_parcels_geom.sql:10). Impact: docstring (env.py:1-2) обещает регистрацию всех моделей для детекции дрейфа схемы, но (a) 'alembic revision --autogenerate' эмитит op.create_table('parcels', ...) для несуществующей таблицы; (b) даёт нулевое покрытие для job_settings и остальных ~50 prod-таблиц. Латентно, т.к. versions/ пуст (миграции применяются raw SQL из data/sql/*.sql), но инструмент выглядит рабочим и активно вводит в заблуждение. Fix: либо импортировать все ORM-модели в app/models/__init__.py (и подтянуть его в env.py), включая JobSetting; либо, если ORM-модели не отражают реальную схему (см. parcel.py), удалить фейковый Parcel и честно задокументировать, что autogenerate здесь не используется. **Почему баг:** Drift detection is the stated, sole purpose of this env.py (alembic/versions/ is empty except .gitkeep — migrations are applied via raw data/sql/*.sql). Because metadata holds only the phantom `parcels` table: (a) `alembic revision --autogenerate` generates `op.create_table('parcels', ...)` for a table that must never exist, and (b) it gives ZERO coverage for the tables it claims to watch, including the actively-used job_settings table. The comment 'Add new model modules here as they appear' was simply not followed for job_settings. The tooling looks like it provides drift detection but is effectively non-functional and actively misleading. **Как чинить:** Either import every real model module in env.py (and have models/__init__.py re-export them) so Base.metadata reflects the real schema, OR — since migrations are hand-written SQL and these ORM models map to phantom/legacy tables — disable autogenerate (target_metadata = None) and drop the misleading docstring. At minimum add `from app.models import job_settings # noqa: F401`. --- <sub>deep-audit backend v2 (после PR #1543) · verify+harden, confidence 0.9 · unit B07</sub>