lekss361/gendesign
1
0
Fork 0
Code Issues 143 Pull requests Projects Releases Packages Wiki Activity Actions

docs(mera/sales-vs-listings): якорь и докстринг по замечаниям ревью PR #3461
All checks were successful
CI Trade-In / changes (pull_request) Successful in 9s
Details
CI / changes (pull_request) Successful in 11s
Details
CI / backend-tests (pull_request) Has been skipped
Details
CI / openapi-codegen-check (pull_request) Has been skipped
Details
CI Trade-In / browser-tests (pull_request) Has been skipped
Details
CI Trade-In / frontend-checks (pull_request) Has been skipped
Details
CI / frontend-tests (pull_request) Has been skipped
Details
CI Trade-In / backend-tests (pull_request) Successful in 5m15s
Details

Browse source 
Ревью справедливо поймало два места, где текст после снятия предиката стал
неточным:

1. Якорь в deploy/import-rosreestr.sh обещал «потребителей, фильтрующих по
   d.rooms, больше нет» — это верно только про предикаты РАВЕНСТВА.
   app/tasks/asking_to_sold_ratio.py:148,152 по-прежнему КЛЮЧУЕТСЯ этим
   бакетом (GROUP BY LEAST(GREATEST(rooms,0),4)) и намеренно зеркалит ту же
   синтетику на листинговой стороне (#2620). Прежняя формулировка сказала бы
   будущему редактору, что проверять некого, — а в сценарии «поменяли CASE на
   реальную комнатность» вернулся бы именно #2620.

2. Докстринг GET /sales-vs-listings обещал listing «с такими же rooms». После
   снятия предиката это верно для пары запрос↔объявление, но не для пары
   сделка↔объявление: deal_rooms может не совпадать с запрошенным rooms.

Кода правка не касается. Полный сьют: 5946 passed, 35 skipped; ruff чист.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
bot-backend 2026-09-12 13:55:40 +05:00
parent 4053adad06
commit de2d67c7f9
2 changed files with 12 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
tradein-mvp/backend/app/api/v1/trade_in.py
View file

@ -2488,8 +2488,12 @@ def get_sales_vs_listings(
"""Pairs (ДКП-сделка, listing) для улицы целевого адреса (PR K / #564).
Для каждой ДКП-сделки Росреестра в окне `period_months` пытаемся найти
matching listing на той же улице с такими же rooms / близкой area_m2 /
listing_date в окне [deal_date - window_days, deal_date + 30d grace].
matching listing на той же улице с близкой area_m2 / listing_date в окне
[deal_date - window_days, deal_date + 30d grace]. Комнатность в ключе стоит
ТОЛЬКО на стороне объявлений (`l.rooms = p_rooms`, комнатность клиента): у
сделок Росреестра `rooms` — синтетика из площади, предикат по ней снят
миграцией 300 (#3451/#3256). Поэтому `deal_rooms` в паре может не совпадать
с запрошенным `rooms`.
Возвращаем LEFT JOIN: сделки без listing match сохраняются (listing_* = None),
чтобы вычислить linkage_rate.

7
tradein-mvp/deploy/import-rosreestr.sh
View file

@ -76,10 +76,15 @@ docker exec "$SRC_PG" psql -U "$SRC_USER" -d "$SRC_DB" -v ON_ERROR_STOP=on -c "
-- НЕ фильтруют по deals.rooms ИМЕННО потому, что здесь синтетика; с
-- настоящей комнатностью предикат нужно вернуть, иначе все сайты молча
-- продолжат ключеваться площадью.
-- Потребителей, фильтрующих по d.rooms, БОЛЬШЕ НЕТ: последний —
-- Потребителей, фильтрующих РАВЕНСТВОМ по d.rooms, больше нет: последний —
-- TVF street_sales_vs_listings — расчищен миграцией 300 (#3451). Ключ там
-- асимметричный: d.rooms снят, l.rooms ОСТАВЛЕН (у объявлений комнатность
-- настоящая). Появится новый потребитель — сверься с этим якорем.
-- НО: app/tasks/asking_to_sold_ratio.py:148,152 по-прежнему КЛЮЧУЕТСЯ этим
-- бакетом (GROUP BY LEAST(GREATEST(rooms,0),4)) и намеренно зеркалит ту же
-- синтетику на листинговой стороне (#2620). Поменяешь CASE на реальную
-- комнатность — вернётся именно #2620 (миграция 23-55% объявлений между
-- бакетами, ratio>1 в «4+»), а не только вопрос предикатов.
CASE
WHEN area < 30 THEN 0 WHEN area < 44 THEN 1
WHEN area < 62 THEN 2 WHEN area < 85 THEN 3