gendesign/data/sql/191_land_reservation_act_date_backfill.sql

-- 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;