При активной разработке в среде 1С:Предприятие 8 программисты часто сталкиваются с ситуацией, когда после получения изменений из хранилища кнопка «Вернуться к конфигурации базы данных» становится неактивной. Это вызывает определенные трудности, особенно если полученные доработки оказались ошибочными или преждевременными для текущего сеанса работы. В этой статье мы подробно разберем, почему платформа ведет себя именно так, в чем отличие работы с расширениями и какие существуют методики для «отката» изменений в условиях подключенного хранилища.
Для начала разберем внутреннюю механику взаимодействия трех составляющих: Основной конфигурации (которую мы видим в дереве объектов), Конфигурации базы данных (реальная структура таблиц в SQL или файловом варианте) и Хранилища конфигурации.
Когда база данных подключена к хранилищу, платформа переходит в особый режим контроля версий. Основная причина блокировки функции возврата к конфигурации БД заключается в обеспечении целостности связей. Платформа 1С жестко связывает состояние основной конфигурации с индексами версий в хранилище. Рассмотрим подробнее: как только мы нажимаем «Обновить конфигурацию из хранилища», локальные метаданные заменяются новыми версиями из репозитория. В этот момент локальная база данных начинает считать, что «точкой истины» теперь является именно состояние хранилища.
Если бы платформа позволила выполнить стандартный откат к конфигурации БД, возникла бы критическая коллизия: в основной конфигурации оказались бы старые объекты, но в служебных таблицах хранилища (локальном кэше) за базой числились бы уже новые версии. Это привело бы к невозможности корректного захвата объектов или их помещения обратно в хранилище без полной перепривязки конфигурации. Разработчики платформы решили эту проблему радикально — просто заблокировав возможность возврата, принуждая разработчика следовать цепочке Хранилище -> Основная конфигурация -> Конфигурация БД.
Многие замечают, что для расширений функция возврата остается доступной даже при использовании хранилища расширений. Проанализируем ситуацию: почему такая несправедливость? Выясним причину в архитектурных различиях:
Если нам все же необходимо вернуть объекты к состоянию, которое сейчас зафиксировано в базе данных (до того, как мы нажали F7), мы можем воспользоваться механизмом сравнения. Разберем по шагам, как это сделать правильно:
Важный нюанс: Этот метод позволяет вернуть код и структуру объектов назад, но статус объектов в хранилище не изменится. Если объекты были захвачены вами, они останутся захваченными. Если они не были захвачены, платформа может выдать предупреждение при попытке редактирования, так как «взломать» логику соответствия версий таким образом не получится — это лишь временная мера для запуска отладки на старом коде.
Рассмотрим ситуацию, когда мы сами внесли изменения, еще не обновили конфигурацию БД, но поняли, что совершили ошибку. В этом случае правильным алгоритмом работы с хранилищем будет использование штатных команд:
Если объект захвачен вами, используйте команду «Отменить захват». Платформа спросит, нужно ли сохранить изменения. При нажатии «Нет» объект автоматически вернется к тому состоянию, в котором он находится в хранилище (которое, как правило, совпадает с конфигурацией БД, если вы работаете в одиночку или изменения коллег еще не приняты).
Если же вы уже получили чужие изменения из хранилища и хотите от них избавиться, проанализируем ситуацию: по факту, «откатиться» назад в рамках одного хранилища можно, только получив конкретную старую версию.
// Пример логики действий разработчика (условно):
1. Открыть историю хранилища.
2. Найти версию, которая была до обновления.
3. Выполнить команду "Получить" для конкретной версии объекта.
Для опытных разработчиков, столкнувшихся с масштабным «загрязнением» конфигурации после неудачного обновления из хранилища, существует более радикальный, но надежный способ. Разберем его по шагам:
.cf)..cf).Проанализируем одно из сообщений форума, где обсуждается подключение боевых баз к общему хранилищу. Это считается плохой практикой именно из-за невозможности быстрого и безопасного отката. Посмотрим, как выстроить процесс правильно:
Иногда знак восклицания <!> (признак отличия основной конфигурации от конфигурации БД) горит, но реальных изменений вроде бы нет. Рассмотрим подробнее, почему так происходит. При обновлении из хранилища платформа обновляет не только метаданные объектов, но и служебную информацию (версии, метки, информацию о правах). Даже если визуально код не изменился, для системы это «новая конфигурация».
Резюмируем: Ограничение платформы — это не ошибка, а защитный механизм. Он предотвращает ситуацию, когда локальный кэш версий хранилища разойдется с реальным состоянием метаданных. Если вам жизненно необходим откат — используйте сравнение/объединение с конфигурацией БД как наиболее безопасный и контролируемый метод ручного возврата состояния объектов.