При поддержке баз данных, особенно с использованием узлов РИБ (распределенной информационной базы), программисты часто приходят к решению вынести добавленные нетиповые реквизиты из основной конфигурации в расширение. Это позволяет упростить процесс обновления и поддержки. Разберем подробно, как правильно осуществить перенос уже заполненных данных, с какими подводными камнями придется столкнуться и почему в некоторых случаях от этой идеи лучше отказаться.
Прямого штатного механизма (например, через стандартное СравнениеИОбъединениеКонфигураций), который бы автоматически перенес реквизит вместе с сохраненными данными из основной конфигурации в расширение, в платформе 1С не предусмотрено. Проанализируем по шагам, как выполнить эту процедуру программным путем.
Перенос всегда осуществляется вручную по следующему алгоритму:
Если объем переносимых данных велик (миллионы записей), процесс записи объектов может занять часы. В таких случаях рекомендуем распараллеливать обработку через ФоновыеЗадания для значительного ускорения процесса.
Рассмотрим технические ограничения платформы, о которых нужно помнить до начала рефакторинга. Полноценная возможность добавлять собственные реквизиты и структуры для хранения данных появилась только начиная с версии платформы и режима совместимости 8.3.11. В более старых режимах совместимости хранить данные в расширениях невозможно.
Также при добавлении реквизитов в расширение стоит учитывать архитектурные ограничения. Например, если при расширении данных формируется составной тип, платформа не позволит включить в него определенные системные типы. В частности, в расширениях недоступно использование таких типов, как ХранилищеЗначения или УникальныйИдентификатор. Если ваши старые реквизиты имели такие типы, их перенос напрямую невозможен.
Посмотрим на более сложную ситуацию. Если вы планируете перенести в расширение не просто строковый или числовой реквизит, а целый самописный справочник или документ (который выступает типом для множества других реквизитов по всей базе), потребуется написать сложную логику замены ссылок.
Вам предстоит выполнить глобальный поиск и замену ссылок по всей базе данных. Необходимо будет найти все места, где использовалась ссылка на старый объект из основной конфигурации, и заменить ее на ссылку нового объекта из расширения. Это критически важно, чтобы не нарушить ссылочную целостность базы данных. Для этого обычно используется функционал ПоискСсылокНаОбъекты.
Теперь проанализируем практический опыт разработчиков и серьезные риски, связанные с расширениями. Как показывает практика, в первый раз хочется вынести в расширения всё. Но со временем всплывают ошибки потери данных при выполнении "Тестирования и исправления" (ТиИ) и разные мелкие неудобства работы.
Выясним главную причину потенциальной потери данных. Платформа 1С строго контролирует свойства заимствованных объектов. Если при обновлении основной конфигурации изменится какое-либо контролируемое свойство объекта, к которому привязано расширение, оно просто не подключится при запуске в пользовательском режиме.
В этот момент данные из расширения станут недоступны. И хотя физически они могут оставаться в СУБД до реструктуризации, риски их безвозвратной потери крайне высоки:
Резюме: Если у вас полностью нетиповая (самописная) конфигурация, опытные разработчики советуют отказаться от использования расширений для хранения данных. Расширения в первую очередь предназначены для типовых конфигураций, находящихся на поддержке поставщика, для простоты накатывания регулярных типовых обновлений. В полностью нетиповой конфигурации добавление реквизитов напрямую в основную ветку метаданных всегда надежнее и безопаснее, а расширения лучше оставить для мелких оперативных багфиксов.