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