С развитием платформы «1С:Предприятие 8.3» механизм расширений стал основным инструментом кастомизации тиражных решений, таких как «1С:ERP Управление предприятием 2» или «1С:Комплексная автоматизация». Одной из самых мощных возможностей расширений является создание собственных объектов метаданных: справочников, документов, регистров сведений и реквизитов. Однако у многих разработчиков возникает резонный вопрос: насколько надежно хранятся эти данные и что произойдет с ними при обновлении или удалении расширения? В этой статье мы подробно разберем внутреннюю кухню хранения данных расширений, проанализируем поведение системы при различных манипуляциях и выработаем стратегию безопасной разработки.
Разберем, каким образом платформа взаимодействует с системой управления базами данных (PostgreSQL, MS SQL Server и др.) при добавлении объектов через расширение. Когда мы создаем собственный справочник или документ в расширении, платформа не просто хранит его «где-то в памяти» — она инициирует полноценную реструктуризацию базы данных. Рассмотрим два сценария:
_ReferenceX_ExtY. Это позволяет платформе четко разделять таблицы основной конфигурации и дополнительные данные.Сотрудники, добавляя в него новый реквизит, ситуация становится интереснее. Согласно архитектуре «1С:Зазеркалье», создается так называемая «расширенная таблица». В нее переносятся данные из основной таблицы, и добавляются колонки для новых реквизитов из всех активных расширений. При этом все запросы к объекту переадресовываются к этой новой структуре. Важно понимать: даже если расширений несколько, расширенная таблица для одного объекта будет создана одна.Проанализируем поведение системы в зависимости от того, какое действие мы совершаем в режиме «1С:Предприятие» или через Конфигуратор. Это самый важный момент для обеспечения сохранности данных.
Вариант 1: Снятие флага «Активно» (Отключение)
Если мы просто отключаем расширение (флажок Активно в списке расширений), данные в базе сохраняются. Таблицы в СУБД никуда не исчезают, они просто становятся недоступными для текущего сеанса работы. Как только флаг будет возвращен на место, все записи в справочниках и документах расширения снова появятся в интерфейсе. Рассмотрим пример: мы создали расширение для учета внутренних документов. При его отключении пользователи перестанут видеть подсистему и сами документы, но как только администратор включит расширение обратно — данные будут на месте.
Вариант 2: Удаление расширения из списка
Здесь кроется главная опасность. Удаление расширения равносильно удалению объекта метаданных из основной конфигурации. Платформа воспринимает это как команду на уничтожение соответствующих структур. При удалении:
Посмотрим на практический опыт: современные версии платформы (начиная с 8.3.15) при попытке удаления расширения, содержащего данные, выдают список объектов, которые будут стерты. Однако полагаться только на предупреждение нельзя — всегда делайте копию перед такими операциями.
Выясним, почему платформа накладывает ограничения на изменение структуры существующих регистров. Представим ситуацию, что мы добавили измерение в типовой регистр сведений через расширение. Если бы это было разрешено, уникальность записей стала бы зависеть от этого нового поля. При отключении расширения база данных столкнулась бы с проблемой: записи, которые были уникальны с учетом нового измерения, могут стать дублями без него. Это привело бы к логическому разрушению базы.
Именно поэтому в расширениях:
Рассмотрим ситуацию, когда реквизит виден в одной базе, но отсутствует в другой при одинаковом коде. Часто причиной является Режим совместимости. Для стабильной работы с собственными объектами расширений крайне желательно, чтобы режим совместимости основной конфигурации был не ниже 8.3.12. В более старых режимах механизмы реструктуризации данных через расширения работают нестабильно или имеют существенные ограничения. Если вы работаете с ERP 2.4/2.5, обычно проблем с этим нет, так как там используются актуальные версии платформы.
Для того чтобы ваша «надстройка» поверх ERP работала стабильно и не вызывала головной боли при обновлениях, придерживайтесь следующих правил:
1. Используйте флаг «Использует данные». В свойствах расширения в Конфигураторе обратите внимание на этот признак. Если он включен, расширение может создавать таблицы. Если вы разрабатываете только косметические изменения интерфейса, лучше этот флаг отключать.
2. Документируйте структуру. При передаче системы заказчику обязательно указывайте, что удаление расширения приведет к потере данных. Хорошей практикой является добавление в договор пункта о том, что восстановление данных после случайного удаления расширения пользователем является отдельной платной услугой.
3. Проверяйте расширение в копии перед обновлением. При обновлении основной конфигурации (например, переход с ERP 2.4 на 2.5) расширение может «отвалиться» из-за изменения заимствованных объектов. В этом случае данные в СУБД останутся, но само расширение не подключится. Вам нужно будет исправить ошибки в Конфигураторе, чтобы вернуть доступ к данным.
4. Работа с ссылочной целостностью. Помните, что если вы создали в расширении Справочник.ДопРеквизиты и использовали его как тип в типовом документе РеализацияТоваровУслуг, то при удалении расширения в типовом документе вы получите «битые ссылки» (Объект не найден).
Подведем итог: механизм собственных объектов в расширениях на современных платформах (8.3.18+) работает достаточно надежно для промышленной эксплуатации. Главное — четко понимать разницу между временным отключением функционала и физическим удалением метаданных из системы.