bot-backend
4e6ed8c044
All checks were successful
CI Trade-In / changes (pull_request) Successful in 7s
CI / changes (pull_request) Successful in 9s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Successful in 1m58s
CI / backend-tests (pull_request) Successful in 17m21s
#2981 починил извлечение даты, но только ВПЕРЁД: UPSERT загрузчика заканчивается `ON CONFLICT DO NOTHING`, а не DO UPDATE, поэтому пятничный прогон (`0 7 * * fri`) существующие строки не перезапишет. Без этой миграции 11 строк остались бы с датой 2004 года навсегда — правка выглядела бы сделанной, а данные на проде остались бы кривыми. Замер прода 20.08.2026: 89adb28a… развязка Базовый/Комсомольская/Сибирский тракт 9 строк 9b9d9a99… улица Энергостроителей 2 строки обе группы: act_date = 2004-07-06 Верные даты не угаданы: оба PDF загружены с екатеринбург.рф и распознаны тем же трактом, что использует загрузчик (ocr_pdf_text), и в обоих настоящее основание — постановление Администрации города: № 1413 от 27.05.2022 и № 259 от 12.02.2020 соответственно. Сужение по doc_url обязательно: без него UPDATE задел бы любую строку с 06.07.2004, включая те, где эта дата настоящая. Миграция идемпотентна — условие `act_date = '2004-07-06'` при повторе не выполнится. Тест герметичный, прогоняет ТЕЛО миграции целиком на временной копии в прод-форме (9+2 целевых + 2 контрольных посторонних). Контроль-двойник `test_without_the_migration_rows_stay_wrong` обязателен: без него тест неотличим от «оно и так было правильно». Мутационно проверено сужение — снятие условия по doc_url роняет test_other_documents_with_same_date_are_untouched. pytest backend/tests/sql/test_2464_act_date_backfill.py — 6 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
42 lines
2.8 KiB
PL/PgSQL
42 lines
2.8 KiB
PL/PgSQL
-- 191: разовое исправление act_date у строк, куда уехала дата Генплана-2004 (#2464).
|
||
--
|
||
-- До #2981 `_extract_act_date` брал ПЕРВОЕ «от DD.MM.YYYY» во всём OCR-тексте.
|
||
-- «Сообщение о планируемом изъятии» открывается списком оснований, где первой
|
||
-- строкой стоит «Решение Екатеринбургской городской Думы от 06.07.2004 № 60/1
|
||
-- «Об утверждении Генерального плана города»». Эта дата и попадала в act_date.
|
||
--
|
||
-- #2981 чинит извлечение, но только ВПЕРЁД: UPSERT загрузчика заканчивается
|
||
-- `ON CONFLICT DO NOTHING`, а не DO UPDATE, поэтому следующий недельный прогон
|
||
-- (пятница 07:00) существующие строки не перезапишет. Без этой миграции 11 строк
|
||
-- остались бы с датой 2004 года навсегда.
|
||
--
|
||
-- Верные даты взяты не из догадки: оба PDF загружены с екатеринбург.рф и
|
||
-- распознаны тем же трактом, что использует загрузчик (ocr_pdf_text), и в обоих
|
||
-- настоящее основание — постановление Администрации города:
|
||
--
|
||
-- 89adb28a… развязка Базовый/Комсомольская/Сибирский тракт
|
||
-- «Постановление Администрации города Екатеринбурга
|
||
-- от 27.05.2022 № 1413 «Об утверждении проекта планировки…»» → 9 строк
|
||
-- 9b9d9a99… улица Энергостроителей
|
||
-- «Постановление Администрации города Екатеринбурга
|
||
-- от 12.02.2020 № 259 «Об утверждении проекта планировки…»» → 2 строки
|
||
--
|
||
-- Идемпотентна: условие `act_date = '2004-07-06'` при повторном запуске не
|
||
-- выполнится. Сужение по doc_url обязательно — без него UPDATE задел бы любую
|
||
-- будущую строку, где 06.07.2004 окажется настоящей датой акта.
|
||
|
||
BEGIN;
|
||
|
||
SET LOCAL lock_timeout = '5s';
|
||
|
||
UPDATE land_reservation
|
||
SET act_date = DATE '2022-05-27'
|
||
WHERE act_date = DATE '2004-07-06'
|
||
AND doc_url LIKE '%89adb28a3677e7df933e2d9ce0f205c8';
|
||
|
||
UPDATE land_reservation
|
||
SET act_date = DATE '2020-02-12'
|
||
WHERE act_date = DATE '2004-07-06'
|
||
AND doc_url LIKE '%9b9d9a998f578db56315bb816fc2ebf5';
|
||
|
||
COMMIT;
|