Перейти к содержимому

Обработчики обновления ИБ — идемпотентные и порционные

Директивный

v8std#std690

#миграции#надёжность#логирование

Любое изменение структуры данных (новый реквизит, который должен быть заполнен; перенос данных между реквизитами; смена формата хранения) сопровождается обработчиком обновления ИБ. Требования к обработчику:

  • Идемпотентность. Повторный запуск (после падения на середине, при повторном обновлении) не портит данные: обработчик выбирает только необработанные записи (ГДЕ НовыйРеквизит = НеЗаполнено), а не «все подряд».
  • Порционность. Большие объёмы обрабатываются пачками; для типовых на БСП — отложенные обработчики, чтобы не держать пользователей на заставке «Обновление…» часами.
  • Логирование. Старт, объём, финиш и каждая ошибка — в ЖР. Ошибка по одному объекту не валит обновление целиком: объект пропускается с записью в ЖР и разбирается после.
  • Обработчик тестируется на копии боевой базы, а не только на пустой ИБ разработчика.

Обработчик обновления выполняется один раз на каждой базе — и именно в момент, когда откат сложнее всего (окно обновления, пользователи ждут). Неидемпотентный обработчик после обрыва на 70% при повторном запуске задваивает данные первых 70%. Обработчик без порций держит монопольный режим часами. Ошибка без перехвата оставляет базу в полуобновлённом состоянии посреди ночи.

Изменения метаданных, не требующие преобразования данных (новый необязательный реквизит, новая форма, правка кода), обработчика не требуют. Разовые правки данных на одной базе допустимо делать обработкой — но с теми же требованиями идемпотентности и логирования.