Каждый разработчик и администратор баз данных «1С:Предприятие» рано или поздно сталкивается с необходимостью доработки типовой конфигурации. Для этого в системе предусмотрен механизм включения возможности изменения. При этом платформа предлагает нам выбрать правила поддержки для объектов поставщика.
Часто у специалистов возникает соблазн установить для всех объектов правило «Объект поставщика редактируется с сохранением поддержки» (снять «замочки» со всей конфигурации), чтобы в будущем не отвлекаться на точечное включение возможности изменения. В этой статье мы подробно разберем, как это решение влияет на производительность системы при последующих обновлениях, проанализируем внутренние механизмы платформы и выясним, почему «замочки» на самом деле критически важны для быстродействия.
Когда мы открываем настройку поддержки в конфигураторе и включаем возможность изменения, платформа предлагает нам настроить правила для объектов. Основной выбор обычно строится между двумя вариантами:
Выясним, влияет ли массовое снятие «замочков» на скорость последующих обновлений и есть ли техническая разница в поведении платформы при сопоставлении объектов.
Главное техническое различие между объектом «на замке» и объектом «без замка» кроется в алгоритме, который платформа использует при обновлении конфигурации. Процесс штатного обновления через меню «Поддержка» — «Обновить конфигурацию» базируется на механизме трехстороннего (триадного) сравнения.
Рассмотрим подробнее, как ведет себя платформа в зависимости от установленного правила поддержки:
Для платформы наличие «замочка» — это жесткая гарантия того, что объект не подвергался никаким изменениям со стороны пользователя или внедренца. Платформа «знает», что его текущее состояние в основной конфигурации абсолютно идентично состоянию в старой конфигурации поставщика. В этом случае сложный попиксельный и построчный анализ структуры метаданных и модулей не требуется. Платформа просто замещает (перезаписывает) старый объект новым из файла обновления. Этот процесс происходит практически мгновенно.
Даже если вы физически не внесли ни единой строчки кода в модуль этого объекта и не добавили ни одного реквизита, отсутствие «замочка» сигнализирует платформе о потенциальном изменении. Платформа обязана запустить полный цикл трехстороннего сравнения по следующей схеме:
Основная конфигурация <—> Старая конфигурация поставщика <—> Новая конфигурация поставщика
Система начинает детально сравнивать свойства, реквизиты, табличные части, формы, макеты и модули объекта, чтобы выявить ваши потенциальные правки и не затереть их при обновлении. На этот глубокий анализ тратится значительное количество процессорного времени и оперативной памяти.
Проанализируем две различные ситуации работы с конфигурацией, чтобы понять, в каких сценариях наличие «замочков» дает реальный прирост скорости:
При использовании стандартного файла обновления (формата .cfu или полного .cf) через механизмы поддержки разница в скорости будет колоссальной. На крупных современных конфигурациях, таких как «1С:ERP Управление предприятием», «1С:Комплексная автоматизация» или «1С:Управление торговлей», количество объектов исчисляется тысячами. Если снять замки со всей конфигурации, процесс сопоставления объектов может затянуться на часы, так как платформа будет вынуждена проводить триадный анализ для каждого справочника, документа и общего модуля. Если же замки сняты только с измененных объектов (которых обычно не более 5-10% от общего объема), обновление пройдет в разы быстрее.
Если вы запускаете процесс через меню «Конфигурация» — «Сравнить, объединить с конфигурацией из файла», то правила поддержки на этапе самого сравнения игнорируются. В этом режиме платформа выполняет стандартное двухстороннее сравнение «всего со всем» по идентификаторам и именам метаданных. В данном сценарии разницы в скорости анализа вы не заметите, однако этот метод не является штатным способом автоматического обновления конфигураций поставщика.
Помимо потери скорости, массовое снятие «замочков» порождает еще одну серьезную проблему — появление ложных «дважды измененных» объектов в окне сравнения при обновлении. Это происходит из-за того, что платформа фиксирует малейшие расхождения, которые могут быть вызваны внутренними причинами:
Если бы эти объекты находились под замком, они обновились бы автоматически. Но поскольку замки сняты, платформа выведет их в список измененных, и разработчику придется вручную анализировать каждый такой объект, тратя драгоценное время на подтверждение того, что реальных изменений там нет.
Если вы по ошибке или незнанию сняли «замочки» со всей конфигурации (установив режим «Редактируется с сохранением поддержки»), вернуть систему в исходное чистое состояние будет крайне непросто. Платформа «1С:Предприятие» не предоставляет возможности массово в один клик вернуть неизмененные объекты под замок с автоматическим анализом их чистоты.
Вам придется выполнять трудоемкую ручную работу:
ОбъектПоставщикаНеРедактируется.Подводя итог, мы можем с уверенностью сказать: разница есть, и она огромна. Правильная настройка поддержки напрямую влияет как на скорость выполнения технических операций, так и на трудозатраты разработчика при сопровождении информационной системы.
Рекомендуем придерживаться следующих правил при кастомизации конфигураций: