1с идентификаторы объектов метаданных зачем он
БСП 2.4, конфа типовая УНФ 1.6
В расширении добавлен регистр сведений (совместимость на 8.3.11 переключена). В справочник идентификаторов объектов метаданных данный экземпляр автоматом не попадает. А если создать обработкой, то через какое-то время он все равно куда-то девается.
Кто-то сталкивался, почему БСП игнорит расширение в данном случае и как она это делает?
(0)[то через какое-то время он все равно куда-то девается.]
помониторь версионированием
чудес не бывает
Общие правила обмена объектами метаданных между конфигурациями
В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:
- Копирование объектов метаданных через буфер обмена
- Объединение конфигурации с файлом
- Загрузка конфигурации из файла
- Хранилище конфигурации
- Обновление конфигурации, находящейся на поддержке
- Обновление конфигурации базы данных
В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по «цепочкам» конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.
Сопоставление объектов. Имя и идентификатор объекта метаданных
При перемещении объектов между конфигурациями важную роль играет вопрос их сопоставления. Необходимо иметь возможность определить, являются ли два данных объекта разными объектами или копиями одного и того же объекта. Предположим, что мы тем или иным способом скопировали объект из одной конфигурации в другую, а затем выполнили объединение этих конфигураций. Естественно ожидать, что платформа определит соответствие двух объектов, а не будет считать их разными объектами с одинаковыми именами. Для сопоставления объектов используются имя и внутренний идентификатор объекта. И если имя в процессе перемещения объекта, как правило, не изменяется (в любом случае мы можем его контролировать и, при необходимости, модифицировать), то внутренний идентификатор объекта ведет себя по-разному в зависимости от используемого механизма. В приведенной ниже таблице описываются способы сопоставления объектов и поведение внутренних идентификаторов при использовании разных механизмов.
При отключенной возможности изменений – сопоставление по идентификаторам. При включенной возможности изменений – сопоставление по идентификаторам, которые в некоторых случаях могут отличаться. В некоторых ситуациях возможна ручная установка соответствия.
Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:
- Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
- Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при включенной возможности изменений.
- Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.
Можно определить следующее правило:
Для обеспечения корректного сопоставления объектов уровень механизмов нельзя понижать.
Например, имеются две конфигурации: одна, в которой ведется разработка и вторая — в «рабочей» базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для «старых» объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в «рабочую» базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов «восстановятся» с точки зрения конфигурации разработки, но изменятся с точки зрения «рабочей» конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.
Примеры
Параллельное создание объектов
Используется одна конфигурация в двух разных базах: в базе разработки и в базе заказчика. При обновлении конфигурации заказчика, была на месте произведена доработка, в результате которой в базу был добавлен новый объект. Затем в конфигурации разработки этот объект был добавлен вручную. Фактически мы воспользовались механизмом третьего уровня (поскольку идентификаторы у объектов получились разные). Для дальнейшей синхронизации конфигураций без потери данных можно применять только объединение (механизм третьего уровня). Для того, что бы избежать подобных проблем, следует после доработки у заказчика сохранить конфигурацию в файл, а затем загрузить ее в базу разработки.
Восстановление автоматической поддержки конфигурации поставщика
Конфигурация находится на поддержке в полностью автоматическом режиме (с отключенной возможностью изменений). Предположим, что в какой-то момент возможность изменений была включена. Например, это понадобилось для срочного исправления ошибки. После исправления ошибки поставщиком, возникла необходимость отключить возможность изменений для облегчения последующих обновлений. Но это приведет к понижению уровня механизма, а следовательно гарантированного сохранения данных информационной базы при этом добиться будет невозможно. Следует создать новую базу из дистрибутива конфигурации поставщика (с выключенной возможностью изменений) и программно перенести в нее данные.
Примеры анализа цепочки изменений конфигурации
Приведем несколько примеров анализа цепочки изменений конфигурации с точки зрения возможности потери данных.
Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.
Другой пример. Мы ведем разработку конфигурации в некоторой базе и готовим в ней файлы поставки. Кроме того, у нас есть подготовленная демонстрационная база, которую мы поставляем пользователям. После создания файла поставки очередной версии мы загружаем его в демонстрационной базе. Все использованные механизмы работают на первом уровне, поэтому расхождения идентификаторов и потери данных не произойдет.
Для получения более подробной информации по поведению идентификаторов и сопоставлению объектов, мы рекомендуем ознакомиться с циклом статей «Поставка и поддержка конфигураций».
Удаление устаревших объектов метаданных из конфигурации
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. Если при изменении структуры метаданных конфигурации планируется удалить объект метаданных (реквизит, измерение, ресурс и пр.), связанный с записями информационной базы, то необходимо принять решение об удалении или переносе данных этого объекта в новые структуры. При переносе данных в другие объекты рекомендуется придерживаться следующих правил.
1.1. Не удалять из конфигурации устаревшие объекты метаданных и реквизиты безвозвратно, а пометить их как устаревшие, добавив к их именам префикс «Удалить» (англ. «Obsolete» ). Например: реквизит «ОсновнойДоговор» (англ. «MainContract» ) должен быть переименован в «УдалитьОсновнойДоговор» (англ. «ObsoleteMainContract» ).
В синоним устаревшего объекта (реквизита) рекомендуется добавлять префикс «(не используется)» (англ. «(not used)» ), например: «(не используется) Основной договор» (англ. «(not used) Main contract» ). Если же устарел стандартный реквизит, то префикс «(не используется)» также добавляется в его синоним.
1.2. После изменения структуры метаданных следует обеспечить перенос данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации.
1.3. Если удаляемый объект метаданных является документом – регистратором движений, а соответствующие регистры с движениями остаются в составе конфигурации, то необходимо обратить внимание на необходимость сохранения движений. Для сохранения движений документов – устаревших объектов метаданных, рекомендуется:
- Запретить генерацию движений при проведении документов этого вида.
- Запретить снятие пометки удаления для документов этого вида.
- Во всех существующих движениях документов этого вида изменить регистратор на один или несколько замещающих документов-регистраторов: существующих универсальных или специально разработанных. Например «Перенос данных», «Операция».
- Пометить все документы этого вида на удаление.
1.4. Произвести замену во всей конфигурации обращений к устаревшим объектам и реквизитам на обращение к новым данным, поскольку использование устаревших объектов и их реквизитов после изменения структуры метаданных методически неверно. В частности, исключить устаревшие объекты метаданных из всех ролей (кроме ролей ПолныеПрава и АдминистраторСистемы ), подписок на события и т.п., а также удалить у них код, формы, макеты, команды и другие элементы, ставшие избыточными.
Исключение составляет только сам код переноса данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации (см. п.1.2).
1.5. При сортировке устаревших объектов метаданных и реквизитов в дереве метаданных следует придерживаться общих требований к конфигурации.
1.6. Также рекомендуется выполнить очистку устаревших данных с тем, чтобы они не влияли на размер базы и не потребляли ресурсы (при резервном копировании, реструктуризации и других операциях).
В случае сложных (ошибкоемких) алгоритмов переноса данных, такую очистку целесообразно проводить не сразу, а через один или несколько релизов. Тем самым, остается возможность выпуска внепланового релиза для устранения последствий некорректной работы алгоритмов переноса.
2. Необходимость в переносе данных также может возникнуть при пересмотре структуры измерений регистров:
- когда измерение регистра сведений становится не актуальным: удаляется, либо изменяется его тип, либо у измерения составного типа уменьшается состав типов;
- если необходимо снять признак Основной отбор у измерения регистра, который участвует в составе планов обмена (это эквивалентно удалению поля из таблицы базы данных).
В этих случаях удаление поля из таблицы базы данных приведет к ошибке при реструктуризации «Записи регистра стали неуникальными». Поэтому следует создать новый регистр с правильной структурой, а старый отметить как устаревший и перенести записи из старого регистра в новый.
При этом создать новый регистр не требуется, если в регистр добавляется новое измерение или у измерения составного типа расширяется состав типов.
3. Безвозвратно удалять устаревшие объекты метаданных и реквизиты, помеченные префиксом «Удалить» (англ. «Obsolete» ), следует при выпуске очередных версий конфигурации в том случае, если соблюдается одно из условий:
- Переход со «старой» версии конфигурации на новые версии всегда выполняется пользователями последовательно, «через» версию с реализованным переносом данных из «устаревших» объектов метаданных и реквизитов. Например: если в конфигурации версии 1.1 реквизит «ОсновнойДоговор» был помечен как устаревший, то переход с версии 1.0 на версию 2.0 всегда выполняется только последовательно: сначала на версию 1.1 (в которой происходит обработка устаревших данных), а затем на 2.0 (в которой устаревшие данные могут быть удалены безвозвратно). Непосредственный переход с версии 1.0 на 2.0 технически невозможен (запрещен).
- Вероятность того, что «старой» версией конфигурации еще пользуются, стала нулевой или пренебрежимо малой.
При этом может потребоваться выпустить промежуточный релиз, в котором обеспечить очистку устаревших данных — см. п.1.6. В противном случае, может завершиться ошибкой реструктуризация регистров, в измерениях которых остаются ссылки на устаревшие данные.
1с идентификаторы объектов метаданных зачем он
Что такое объект Метаданные и зачем он может пригодиться?
Объект Метаданные предназначен для доступа к объектам конфигурации, объявленным при ее создании (т.е. в Конфигураторе). Одна из задач, где широко используется метаданные — универсальные обработки, где заранее не известно, с какими видами объектов придется работать. Другая, не менее часто возникающая задача, — универсальная обработка атрибутов похожих но, тем не менее, различных видов объектов (например — одинаковая обработка табличных частей документов, в одном из которых есть «лишнее» поле).
К каким объектам мы можем доступиться, используя Метаданные?
Практически ко всем, объявленным в Конфигураторе: Константа, Справочник, Документ, Журнал, ПланСчетов и т.д.
Синтаксис использования объекта следующий:
Кво = Метаданные.Объект(); // получение количества элементов
МетаОб = Метаданные.Объект(Номер | Идентификатор); // объект метаданных
КвоРекв = МетаОб.Реквизит(); // количество реквизитов
// хотя в некоторых случаях может быть и такой синтаксис:
КвоРекв = МетаОб.Реквизит.Количество; // количество реквизитов
МетаРекв = МетаОб.Реквизит(Номер | Идентификатор); // реквизит объекта
// или для второго случая:
МетаРекв = МетаОб.Реквизит.Получить(Номер); // реквизит объекта
Какой конкретно случай использовать для доступа к объектам — смотрите в документации.
Как видите — доступ к количеству несколько отличается от общепринятого (если такое слово применимо к 1С) получения количества других объектов.
Для проверки существования реквизита с заранее определенным идентификатором используется метод Выбран():
Если Метаданные.Объект(Идентификатор).Выбран()=1 Тогда . // Объект существует
Если МетаОб.Реквизит(Идентификатор).Выбран()=1 Тогда . // Реквизит существует
Объекты метаданных имеют атрибуты, позволяющие определить подробные их характеристики. К таким атрибутам относятся стандартные (Идентификатор, Тип, Вид, Длина, Точность, . ) или специфические для конкретных объектов (ДлинаКода, ДлинаНаименования, ТипНомера, . ).
Приведем простой пример получения списка всех справочников:
Функция СписокДокументов()
Сп=СоздатьОбъект(«СписокЗначений»);
Для И1=1 По Метаданные.Справочник() Цикл
МетаСпр=Метаданные.Справочник(И1);
Сп.Установить(МетаСпр.Синоним, МетаСпр);
КонецЦикла;
Возврат Сп;
КонецФункции
Если я еще не убедил вас в полезности этого объекта — посмотрите, насколько широко он используется в стандартных конфигурациях (только «для Украины»? Или во всех? не знаю. ). Это и «Обработка документов», и функции глЕстьРеквизитШапки, глЕстьРеквизитТабличнойЧасти и другие фичи.
Напоследок рассмотрим более интересный (с практической точки зрения) пример: создание из существующего документа нового, возможно — другого вида.
Процедура КопироватьДокумент(ИсхДок, ВидДок, Сп)
// ИсхДок — исходный документ
// ВидДок — вид нового документа
// Сп — список соответствий реквизитов:
// Значение — реквизит в исходном документе
// Строка — реквизит нового документа
Д=СоздатьОбъект(«Документ.»+ВидДок);
Д.Новый();
МетаДок=Метаданные.Документ(ВидДок);
// Копируем общие реквизиты — для них соответствий не нужно
Для И1=1 По Метаданные.ОбщийРеквизитДокумента() Цикл
ИдРекв=Метаданные.ОбщийРеквизитДокумента(И1).Идентификатор;
// Идентификатор guid уникальный — не копируем!
Если НРег(ИдРекв)=»guid» Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдРекв));
КонецЦикла;
// Копируем реквизиты шапки. Несопоставленные — пропускаем
Для И1=1 По МетаДок.РеквизитШапки() Цикл
ИдРекв=МетаДок.РеквизитШапки(И1).Идентификатор;
ИдИсх=Сп.Получить(ИдРекв);
Если ПустоеЗначение(ИдИсх)=1 Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдИсх));
КонецЦикла;
// Построчно копируем реквизиты табличной части.
// Как и для реквизитов шапки несопоставленные — пропускаем
ИсхДок.ВыбратьСтроки();
Пока ИсхДок.ПолучитьСтроку()=1 Цикл
Д.НоваяСтрока();
Для И1=1 По МетаДок.РеквизитТабличнойЧасти() Цикл
ИдРекв=МетаДок.РеквизитТабличнойЧасти(И1).Идентификатор;
ИдИсх=Сп.Получить(ИдРекв);
Если ПустоеЗначение(ИдИсх)=1 Тогда Продолжить; КонецЕсли;
Д.УстановитьАтрибут(ИдРекв, ИсхДок.ПолучитьАтрибут(ИдИсх));
КонецЦикла;
КонецЦикла;
// Документ скопирован. Запишем и покажем
Д.Записать();
Конт=»»;
ОткрытьФорму(Д.ТекущийДокумент(), Конт, );
КонецПроцедуры
P.S.: Документацию в формате ALS (формат справки 1С) по метаданным можно найти на сайтах, посвященным 1С программированию, например в Клубе профессионалов 1С. Или воспользоваться поиском на yandex.ru.
P.P.S.: Обработку, выполняющую копирование документов можно взять здесь.