В процессе сопровождения и доработки типовых конфигураций 1С, таких как «1С:Розница» или «1С:Управление торговлей», разработчики часто сталкиваются с механизмом создания файлов поставки и обновлений. В норме файл обновления .cfu содержит только «дельту» — разницу между текущей и предыдущей версиями конфигурации. Однако иногда случается технический сбой, при котором даже минимальное изменение одной строки кода приводит к генерации огромного файла обновления размером в сотни мегабайт. Разберем, почему это происходит и как вернуть размер обновлений в норму.
Рассмотрим стандартную ситуацию: ведется разработка собственной поставки на базе типового решения. В течение долгого времени обновления (файлы .cfu) имели объем 1–3 Мб. Однако после масштабного объединения конфигурации с новой подсистемой (например, подсистемой ККТ или Библиотекой стандартных подсистем) размер последующих обновлений резко возрастает до 200–500 Мб. При этом не имеет значения объем вносимых изменений — даже коррекция одной буквы в комментарии заставляет платформу включать в файл обновления огромный массив данных.
Проанализируем ситуацию: почему платформа «пропихивает» в обновление лишние данные? Для этого нам нужно понять механизм формирования «дельты» в 1С.
Файл .cfu не является просто архивом с измененным кодом. Он содержит полные объекты метаданных, которые платформа считает измененными относительно исходной версии поставки. Выясним основные причины, по которым объекты попадают в обновление целиком:
Двоичных данных. При сравнении и объединении конфигураций эти макеты могут перезаписываться. Если платформа фиксирует изменение версии такого макета, он будет целиком попадать в каждое обновление..cfu все описание формы, включая варианты для разных разрешений и настроек. То же касается тяжелых XDTO-пакетов.Если размер файла обновления остается стабильно большим при минимальных изменениях, скорее всего, произошло повреждение внутренней структуры базы данных конфигурации. Обычные средства, такие как Тестирование и исправление (ТИИ) или утилита chdbfl.exe, в этом случае часто оказываются бессильны, так как они проверяют физическую целостность таблиц, а не логическую связность версий объектов в таблицах Config и ConfigSave.
Для решения проблемы воспользуемся методом «перезагрузки» конфигурации через файл .cf. Рассмотрим этот алгоритм подробнее:
.cf..cf. После этого выполним Обновить конфигурацию базы данных..cf. На этом этапе платформа выполняет полную переиндексацию и реорганизацию внутренних таблиц, удаляя «мусорные» версии объектов и исправляя связи GUID-ов..cf через меню Конфигурация -> Загрузить конфигурацию из файла....Важно: При выполнении полной загрузки .cf история изменений объектов внутри конфигуратора обнуляется, что заставляет платформу заново сопоставить объекты метаданных с их образами в файлах поставки. Это устраняет ложные пометки об «изменении» объектов, которые на самом деле не менялись.
Чтобы в будущем избежать неоправданного роста .cfu, проанализируем настройки создания файлов обновления. При генерации обновления через меню Конфигурация -> Распределенная информационная база -> Создать файлы поставки и обновления конфигурации обратите внимание на следующие моменты:
Рассмотрим программный код, который часто приходится корректировать в модуле обновления ИБ (например, ОбновлениеИБРТ), чтобы корректно зарегистрировать изменения:
Процедура ПриДобавленииОбработчиковОбновления(Обработчики) Экспорт
НовыйОбработчик = Обработчики.Добавить();
НовыйОбработчик.Версия = "2.2.13.1"; // Указываем актуальную версию
НовыйОбработчик.Процедура = "ОбщийМодуль.ОбновитьДанныеПользователей";
НовыйОбработчик.Очередь = 1;
КонецПроцедуры
Выясним причину, почему даже при изменении одной строки в этом модуле файл получается большим. При создании .cfu крайне важно правильно выбрать список версий, для которых создается обновление. Если вы выбираете слишком много предыдущих версий, платформа включает в файл цепочку изменений для каждой из них. Старайтесь указывать только последнюю стабильную версию, чтобы минимизировать объем дельты.
Для поддержания базы-разработчика в оптимальном состоянии рекомендуется:
.cfu всегда очищайте локальный кэш конфигуратора (папки %AppData%\1C\1Cv8). Платформа использует временные файлы при сравнении конфигураций, и ошибки в кэше могут влиять на состав включаемых в обновление объектов..cfu с предыдущей версией. Если вы видите, что в список изменений попали роли или макеты, которые вы не трогали, значит, структура базы снова требует «лечения» через .cf.Используя описанный метод полной перезагрузки конфигурации через файл .cf, мы фактически выполняем глубокую реорганизацию метаданных, что является единственным надежным способом исправить «раздутый» файл обновления при повреждении внутренней логики платформы.