При работе в команде над крупными проектами 1С использование хранилища конфигурации становится ежедневной рутиной. Однако даже опытные разработчики иногда сталкиваются с вопросом: как правильно захватить объекты, чтобы внести изменения и при этом не парализовать работу всей команды? В данной статье мы подробно разберем ситуацию создания новых ролей и выясним, почему флаг Захватывать рекурсивно может стать «ядерной бомбой» для процесса разработки.
Рассмотрим ситуацию, когда нам необходимо добавить в конфигурацию две новые роли. Основной вопрос заключается в том, как именно взаимодействовать с корнем конфигурации в хранилище. Для понимания процесса давайте проанализируем, что происходит на техническом уровне при использовании разных режимов захвата.
Когда мы выполняем захват без рекурсии, мы блокируем только сам объект Конфигурация. Это означает, что мы получаем исключительное право на изменение состава дерева метаданных. Мы можем добавлять новые справочники, документы или, как в нашем случае, роли. При этом все существующие объекты остаются доступными для других участников разработки.
Когда же мы выбираем рекурсивный захват, система пытается заблокировать не только корень, но и абсолютно все подчиненные ему объекты: каждый справочник, каждый модуль, каждую форму и каждый макет. В больших конфигурациях (таких как 1С:ERP Управление предприятием или 1С:Комплексная автоматизация) этот процесс может занимать значительное время (иногда часы), в течение которого никто из коллег не сможет поместить свои изменения в хранилище.
Выясним причину, по которой для нашей задачи рекурсия избыточна. При создании новой роли изменения вносятся только в структуру дерева метаданных. Сама роль — это абсолютно новый объект, который еще не существует в хранилище. Следовательно, его не нужно «захватывать» в привычном смысле, так как его еще никто не мог занять.
Важный нюанс, который часто вызывает путаницу: настройка прав в новой роли. Нам может показаться, что для установки прав на справочник Номенклатура внутри нашей новой роли нам нужно захватить сам справочник Номенклатура. Это не так. Права доступа физически хранятся внутри объекта Роль, а не внутри объектов, на которые эти права назначаются. Таким образом, имея захваченным только корень (для регистрации новой роли) и саму созданную роль, мы можем настроить права на любые объекты базы, не мешая коллегам работать с этими объектами.
Разберем по шагам правильную последовательность действий, которая позволит быстро и безопасно добавить роли в хранилище:
Обновить конфигурацию из хранилища. Это гарантирует, что локальная копия метаданных соответствует актуальному состоянию проекта.Хранилище -> Захватить в хранилище.... В появившемся окне не устанавливаем флаг Захватывать рекурсивно.Роль. Настроим в них необходимые права, выбрав нужные документы и справочники в редакторе роли.Поместить в хранилище.... Обратите внимание, что при помещении также не рекомендуется использовать флаг рекурсии без необходимости, так как это заставляет систему проверять статусы всех объектов конфигурации, что существенно замедляет процесс коммита.Проанализируем ситуацию, если вы все же решили использовать рекурсивный захват. Если в этот момент другой разработчик уже захватил какой-то отдельный объект (например, отчет), ваш процесс захвата корня прервется ошибкой. Система 1С не позволяет захватить рекурсивно ветку дерева, если в ней есть объекты, уже занятые другими пользователями.
Если вы случайно начали рекурсивный захват и поняли, что процесс «завис», попробуйте отменить операцию. Если захват уже завершился, наиболее корректным действием будет:
1. Выполнить команду Отменить захват для корня с установленным флагом Рекурсивно.
2. Повторить захват корня уже без рекурсии.
В условиях работы с высоконагруженными хранилищами рекомендуется придерживаться правила минимального захвата. Рассмотрим пример из практики:
Предположим, вам нужно изменить права доступа в существующей роли. Даже в этом случае вам не нужно захватывать корень конфигурации. Достаточно захватить только саму роль. Корень конфигурации (нерекурсивно) требуется захватывать только в трех случаях:
Соблюдение этих простых правил позволит вашей команде работать параллельно, избегая конфликтов блокировок и неоправданного ожидания при взаимодействии с хранилищем 1С.