refactor(tradein): unify kadastr_num → cadastral_number (#732) #891

Merged

lekss361 merged 1 commit from feat/732-cadastral-unify into main

2026-05-31 12:47:10 +00:00

bot-backend commented

2026-05-31 12:42:29 +00:00

Collaborator

Summary

p3 naming-consistency (cadastral columns are 0%-filled across tradein). Migration 094 cadastral_unify.sql (idempotent, DO-block IF EXISTS guards):

drop + recreate listings_search_mv (MV) + v_data_quality (view) with the renamed column;
RENAME deals.kadastr_num + house_metadata.kadastr_num → cadastral_number;
DROP listings.kadastr_num + listings_kadastr_idx (listings.cadastral_number already exists, 0 rows);
REFRESH MATERIALIZED VIEW.
Code SQL-string renames in search_query.py, estimator.py, base.py INSERT (the Lot.kadastr_num dataclass field is intentionally NOT renamed — out of scope, would break scraper→DB mapping).

Test plan

pytest -k "estimator or search or save_listings or base" → 240 passed (1 pre-existing env failure, unrelated); ruff clean.
Live verify (qa/ops): /estimate 200, SELECT 1 FROM v_data_quality/listings_search_mv ok, information_schema.columns has no kadastr_num.

⚠️ MERGE-GATE — destructive DDL, do NOT auto-merge

This migration auto-applies to prod on deploy and is destructive: drops the search MV + data-quality view + a column, renames columns (irreversible without backup). Hold merge until post-demo (2026-06-01) and:

Reviewer/ops: verify the recreated MV + view DDL against the LIVE pg_get_viewdef / pg_matviews definitions before applying — the worker reconstructed them from migration history (050/046), not a live capture, so any later drift would make the recreate wrong.
Take a pg_dump -t deals -t house_metadata -t listings snapshot first; the final REFRESH MATERIALIZED VIEW holds a lock on listings — apply in a low-traffic window.

Refs #732

## Summary p3 naming-consistency (cadastral columns are 0%-filled across tradein). Migration **094** `cadastral_unify.sql` (idempotent, `DO`-block `IF EXISTS` guards): 1. drop + recreate `listings_search_mv` (MV) + `v_data_quality` (view) with the renamed column; 2. RENAME `deals.kadastr_num` + `house_metadata.kadastr_num` → `cadastral_number`; 3. DROP `listings.kadastr_num` + `listings_kadastr_idx` (`listings.cadastral_number` already exists, 0 rows); 4. `REFRESH MATERIALIZED VIEW`. Code SQL-string renames in `search_query.py`, `estimator.py`, `base.py` INSERT (the `Lot.kadastr_num` dataclass field is intentionally NOT renamed — out of scope, would break scraper→DB mapping). ## Test plan - [x] `pytest -k "estimator or search or save_listings or base"` → 240 passed (1 pre-existing env failure, unrelated); ruff clean. - [ ] Live verify (qa/ops): `/estimate` 200, `SELECT 1 FROM v_data_quality/listings_search_mv` ok, `information_schema.columns` has no `kadastr_num`. ## ⚠️ MERGE-GATE — destructive DDL, do NOT auto-merge This migration **auto-applies to prod on deploy** and is **destructive**: drops the search MV + data-quality view + a column, renames columns (irreversible without backup). **Hold merge until post-demo** (2026-06-01) and: 1. **Reviewer/ops: verify the recreated MV + view DDL against the LIVE `pg_get_viewdef` / `pg_matviews` definitions before applying** — the worker reconstructed them from migration history (050/046), not a live capture, so any later drift would make the recreate wrong. 2. Take a `pg_dump -t deals -t house_metadata -t listings` snapshot first; the final `REFRESH MATERIALIZED VIEW` holds a lock on `listings` — apply in a low-traffic window. Refs #732

bot-backend added 1 commit 2026-05-31 12:42:29 +00:00

refactor(tradein): unify kadastr_num -> cadastral_number (#732 ) 42de30cd5c

p3 naming-consistency (cadastral cols 0% filled). Migration 094_cadastral_unify.sql
(idempotent DO-block IF EXISTS): drop+recreate listings_search_mv (MV) +
v_data_quality (view), RENAME deals/house_metadata kadastr_num->cadastral_number,
DROP listings.kadastr_num + listings_kadastr_idx. Code SQL-string renames in
search_query/estimator/base (Lot dataclass field NOT renamed). 240 tests pass.

WARN: destructive DDL auto-applies to prod on deploy -> MERGE-GATE post-demo.
Reviewer: verify recreated MV/view DDL vs LIVE pg_get_viewdef before apply
(reconstructed from migration history 050/046, not live capture).

Refs #732

bot-reviewer requested changes 2026-05-31 12:46:15 +00:00

bot-reviewer left a comment

Collaborator

🔴 HOLD — destructive DDL merge-gate (не мержу).

Миграция 094 auto-applies на prod на деплое и деструктивна: DROP listings.kadastr_num + idx, DROP/recreate listings_search_mv + v_data_quality, RENAME deals/house_metadata.kadastr_num — необратимо без бэкапа.

Критический риск (сам автор флагнул): MV + view реконструированы из истории миграций (050/046), не из live pg_get_viewdef/pg_matviews. Если prod-определения дрейфанули — recreate молча перезапишет search-MV / data-quality-view неправильной версией. Это обязательная human/ops pre-merge проверка против живой БД — я (headless reviewer) live pg_get_viewdef сверить не могу и DDL исполнять не должен (read-only).

Плюс: REFRESH MATERIALIZED VIEW держит lock на listings → low-traffic окно + pg_dump -t deals -t house_metadata -t listings снапшот ПЕРЕД применением. p3, post-demo (не демо-критично).

Код-уровень (для будущего merge): idempotent DO-block IF EXISTS guards разумны; Lot.kadastr_num dataclass намеренно не тронут (scraper→DB mapping) — корректное решение; SQL-string ренеймы в search_query/estimator/base. Но мерж деструктивной DDL за день до демо без live-DDL-сверки и бэкапа = человеческий/ops acт.

→ +needs-human +blocked. Ops: сверить recreate-DDL с live pg_get_viewdef, снять pg_dump, применить post-demo в low-traffic окно.

🔴 **HOLD — destructive DDL merge-gate (не мержу).** Миграция 094 **auto-applies на prod на деплое** и **деструктивна**: DROP `listings.kadastr_num` + idx, DROP/recreate `listings_search_mv` + `v_data_quality`, RENAME `deals/house_metadata.kadastr_num` — необратимо без бэкапа. **Критический риск (сам автор флагнул):** MV + view реконструированы из истории миграций (050/046), **не из live `pg_get_viewdef`/`pg_matviews`**. Если prod-определения дрейфанули — recreate **молча перезапишет** search-MV / data-quality-view неправильной версией. Это **обязательная human/ops pre-merge проверка** против живой БД — я (headless reviewer) live `pg_get_viewdef` сверить не могу и DDL исполнять не должен (read-only). Плюс: `REFRESH MATERIALIZED VIEW` держит lock на `listings` → low-traffic окно + `pg_dump -t deals -t house_metadata -t listings` снапшот ПЕРЕД применением. p3, post-demo (не демо-критично). Код-уровень (для будущего merge): idempotent `DO`-block IF EXISTS guards разумны; `Lot.kadastr_num` dataclass намеренно не тронут (scraper→DB mapping) — корректное решение; SQL-string ренеймы в search_query/estimator/base. Но **мерж деструктивной DDL за день до демо без live-DDL-сверки и бэкапа = человеческий/ops acт.** → `+needs-human +blocked`. Ops: сверить recreate-DDL с live `pg_get_viewdef`, снять `pg_dump`, применить post-demo в low-traffic окно.