data/sql/161_supply_layers_view_devgroup_key.sql

@@ -1,80 +0,0 @@
--- 161_supply_layers_view_devgroup_key.sql
--- #1650 — v_supply_layers_latest collapses L3 dev_groups: fix DISTINCT ON key.
---
--- БАГ: v_supply_layers_latest (м.125) использует DISTINCT ON по 6-колоночному ключу
---   (layer, district_name, complex_id, obj_class, source) — без dev_group_name.
---   После м.128 логический UNIQUE-ключ supply_layers расширен до 7 колонок:
---   (layer, district_name, complex_id, obj_class, dev_group_name, source, snapshot_date).
---   Для L3 (layer=3, domrf_multiphase): complex_id=NULL у ВСЕХ строк, разные dev_group'ы
---   района имеют одинаковый 6-column DISTINCT-ключ → VIEW схлопывает их в 1 строку.
---   Измерено на prod: 8 L3 строк в view (по 1 на район) vs 102 фактических строк в таблице.
---   Например, Академический: view→1 строка (607 юнитов), таблица→48 строк (41 887 юнитов).
---
--- ЧИНИМ: добавляем dev_group_name в DISTINCT ON / ORDER BY view'а.
---   Новый DISTINCT ON ключ:
---     (layer, district_name, complex_id, obj_class, dev_group_name, source)
---   зеркалит логический ключ uq_supply_layers_logical (м.128, без snapshot_date — view
---   берёт max-снапшот, snapshot_date остаётся в ORDER BY как tiebreak).
---
--- Зависимости:
---   • supply_layers (м.125 + м.128) — таблица с колонкой dev_group_name (м.128 обязателен).
---   • v_supply_layers_latest (м.125) — пересоздаётся здесь через CREATE OR REPLACE VIEW.
---   • Проверено: у v_supply_layers_latest нет downstream-зависимых view/matview.
---     CREATE OR REPLACE VIEW безопасен — колонки совместимы (добавляем dev_group_name в конец,
---     существующие колонки 1-13 не переупорядочиваем).
---
--- Idempotent: CREATE OR REPLACE VIEW — повторный прогон перезаписывает view тем же DDL,
---   без ошибок.
--- Deploy: auto-applied через _schema_migrations (ровно один раз по NN).
--- Migration order: м.125 и м.128 уже применены на prod — этот файл идёт ПОСЛЕ них.
---   После применения v_supply_layers_latest сразу вернёт корректные L3 per-dev_group строки
---   без перезапуска воркера (view читает актуальные данные supply_layers напрямую).
-
-BEGIN;
-
--- ── Пересоздать v_supply_layers_latest с dev_group_name в DISTINCT ON ─────────────
--- Ключ: (layer, district_name, complex_id, obj_class, dev_group_name, source)
---   зеркалит uq_supply_layers_logical (м.128). DISTINCT ON требует совпадения ведущих
---   ORDER BY-выражений с DISTINCT-ключом — они перечислены первыми, далее snapshot_date
---   DESC, computed_at DESC, id DESC как детерминированный tiebreak на max-снапшот.
--- dev_group_name добавлена в SELECT как последняя колонка (позиция 14) — CREATE OR REPLACE
---   VIEW в PG допускает добавление колонок в конец списка без пересоздания зависимостей.
--- NULLS NOT DISTINCT логика: view просто делает DISTINCT ON, не UNIQUE-constraint —
---   NULL в dev_group_name у L1/L2 работает как обычный NULL в DISTINCT ON (все L1/L2 строки
---   с dev_group_name=NULL дедуплируются по остальным ключевым полям, что корректно).
-CREATE OR REPLACE VIEW v_supply_layers_latest AS
-SELECT DISTINCT ON (layer, district_name, complex_id, obj_class, dev_group_name, source)
-    id,
-    layer,
-    district_name,
-    complex_id,
-    obj_class,
-    units_estimate,
-    area_estimate,
-    expected_online_date,
-    source,
-    confidence,
-    method,
-    snapshot_date,
-    computed_at,
-    dev_group_name
-FROM supply_layers
-ORDER BY
-    layer,
-    district_name,
-    complex_id,
-    obj_class,
-    dev_group_name,
-    source,
-    snapshot_date DESC,
-    computed_at DESC,
-    id DESC;
-
-COMMENT ON VIEW v_supply_layers_latest IS
-    'Свежий снапшот supply_layers на логический ключ (layer, district_name, complex_id, '
-    'obj_class, dev_group_name, source) — max(snapshot_date), детерминир. tiebreak '
-    'computed_at→id DESC. dev_group_name добавлен в DISTINCT ON в м.161 (#1650): '
-    'без него L3 dev_group''ы района схлопывались в 1 строку (~95.6% потерь). '
-    'Canonical read-path для future-supply (#950 Step6) и UI/forecast.';
-
-COMMIT;