av
b2885c79e3
- экспорт Apple это снапшот всей истории, доставки после его даты — события поверх; состояние пересобирается как import(экспорт) + replay(доставки) - отсюда ретеншен архива меняется с произвольных 14 дней на «до следующего проверенного экспорта» (~2 ГБ за квартал, измерено), а свёртка обязана быть детерминированной — воспроизведение строго по received_at - названы границы модели: stateOfMind в экспорт не попадает вовсе, а верхние слои за периоды с удалёнными доставками не воскресают и досчитываться не должны — каталог обязан говорить это честно
2.2 KiB
Пересборка хранилища из сырого архива
Приоритет: высокий
Разбор пишется по реальным данным и будет ошибаться — это норма, а не риск. Риск в другом: без пересборки ошибка разбора становится потерей данных — исправленный код не применится к тому, что уже разобрано неверно.
Пересчёт по всей истории сразу ещё и точнее приёма: вывод слоя и род агрегации на полном ряду доставок надёжнее, чем на одной.
Проектировать это надо сразу как свёртку по журналу, а не как разовую
утилиту: состояние есть import(снапшот экспорта) + replay(доставки после его даты), и пересборка из архива — вырожденный случай с пустым снапшотом. Тогда
reindex и import окажутся одной операцией с разным входом, а не двумя
похожими.
Отсюда требование, которое легко упустить: свёртка обязана быть
детерминированной. Проигрывание должно давать то же состояние, что приём в
реальном времени. Слияние «выигрывает более полная точка» коммутативно, но две
одинаково полные точки с разными значениями разрешает порядок — значит
воспроизведение идёт строго по received_at, а не по порядку файлов в каталоге.
Готово, когда пересборка с нуля даёт состояние, совпадающее с накопленным приёмом, и повторный прогон ничего не меняет.
Связано: план шаг 3, docs/architecture.md → «Сырой архив».