Ворклог по задаче "Перенести сайт на новый движок"

Структура legacy-БД: гипотеза «просто подключиться» пересматривается

После локального запуска посмотрели фактическую структуру существующей MySQL. Масштаб legacy оказался существенно больше, чем видно только по Docker-стеку: 250 таблиц, около 198 тыс. строк и ~82 MiB данных.

Из 250 таблиц примерно 150 имеют старый MODX-префикс fSdf12_. Это большой системный слой самого MODX и установленных за годы Extras: ACL/policies, contexts, manager/dashboard, media sources, package transport, lexicon, sessions, users/groups, billing/shop-модули, society, SDK/importer, search, monitoring, GeoIP и другие подсистемы. Значительная часть этих таблиц пустая или содержит буквально единицы записей, но при анализе legacy они всё равно выглядят как потенциально значимая часть системы.

Отдельно присутствует ещё один исторический слой модели: десятки Prisma-style relation-таблиц _...; многие из них сейчас пустые. Видны и следы последовательных миграций/дублирования сущностей: например старые и новые варианты Place, Beer, User, Photo, комментариев и связующих таблиц, backup-таблицы пользователей, views и разные storage engines (MyISAM + InnoDB). Это уже не одна предметная схема, а несколько поколений архитектуры, живущих в одной базе.

При этом реальное предметное ядро pivkarta.ru намного меньше. По данным видно несколько тысяч заведений (Place ~3.8k), около 1.6k сортов/позиций Beer, ~13k связей PlaceBeer, фотографии, пользователи и связи заведений с пивом/метро/пользователями; плюс контентные сущности вроде комментариев, тем, новостей/блогов и т.п. Какие именно из них нужны современной версии продукта, ещё предстоит определить по фактическим требованиям — количество записей само по себе не доказывает, что feature надо переносить.

Это наглядно подтверждает тезис из статьи «MODX платит огромную постоянную архитектурную цену за функциональность, которой большинство проектов почти не пользуется»: даже пустая таблица не означает нулевую архитектурную стоимость. Если subsystem существует, при работе с legacy приходится выяснять его модель, связи, runtime semantics и понимать, можно ли его безопасно отбросить. В этой базе эффект хорошо виден буквально физически: большая часть schema описывает возможности движка и исторические эксперименты, а не сегодняшнюю предметную модель pivkarta.ru.

Изменение направления эксперимента

В предыдущем worklog первым вариантом был минимально инвазивный путь: оставить существующую MySQL как persistence boundary и подключить новый API через Knex. После просмотра схемы этот вариант уже не выглядит очевидно оптимальным.

Теперь более перспективная гипотеза — создать новую чистую БД с минимальной предметной моделью и мигрировать в неё только доказанно необходимые данные. Старую БД использовать как источник данных и археологии требований, но не делать её постоянным фундаментом новой архитектуры.

Это добавляет работы сейчас: агенту придётся разобраться, какие из 250 таблиц действительно участвуют в продукте, какие являются техническими таблицами MODX/Prisma/Extras, какие представляют старые версии тех же данных, а какие features вообще больше не нужны. Но именно это и является хорошим brownfield-тестом HAIH: не переносить накопленную сложность только потому, что она уже существует; восстановить реальные требования и собрать под них минимальную новую модель.

Следующий логичный шаг — построить карту legacy tables → реальные capabilities → нужны/не нужны → новая модель → migration/verification, а затем выбрать первый вертикальный сценарий и перенести его вместе с данными end-to-end.

Связанный эксперимент: haih.site и задача /tasks/cmujk0ehv0m20qw0rs14y30bw. Текущая задача: /tasks/cmqqxckd3003zp50up0dmzbld.