1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

Содержание
  1. Работа с метаданными
  2. Прямой доступ к метаданным
  3. Косвенный доступ к метаданным
  4. Загрузка метаданных
  5. Кеширование метаданных
  6. Механизм
  7. Описание и возможности
  8. Устройство механизма
  9. Использование механизма
  10. Управление использованием истории данных
  11. Запись версии
  12. Получение списка версий
  13. 1C и ETL
  14. Внимательный взгляд
  15. Реализация «высокоуровневого» интерфейса
  16. Реализация на СУБД
  17. Data mapping
  18. Подготовка таблицы метаданных
  19. Захват изменений данных
  20. Использовать версии объектов
  21. Использовать план обмена
  22. Глава 39 Работа с Метаданными
  23. Контекст работы с метаданными
  24. Атрибуты и методы объекта «Метаданные»
  25. Методы работы с метаданными
  26. Выбран
  27. Родитель
  28. ПолныйИдентификатор
  29. Представление
  30. ДлинаПредставленияЗначения
  31. Получение информации о структуре хранения базы данных в терминах 1С:Предприятие и СУБД
  32. Получение структуры хранения базы данных
  33. Область применимости
  34. Подготовка базы
  35. Набор таблиц базы данных в СУБД и методе платформы
  36. Набор полей (колонок) в таблице
  37. Состав индексов
  38. Продолжаем эксперименты
  39. Задание для самостоятельной работы
  40. Выводы

Работа с метаданными

1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

Метаданные удаленной конфигурации представляют собой дерево объектов, описывающих состав и свойства следующих объектов системы:

  • коллекций объектов конфигурации;
  • объектов конфигурации (справочников, документов и пр..);
  • реквизитов и табличных частей объектов.

Прямой доступ к метаданным

Дерево метаданных доступно в свойстве “Метаданные” объекта “БромКлиент”. Через данное свойство может быть получен доступ ко всем подчиненным узлам на требуемой глубине:

// Получаем узел коллекции справочников dynamic узелСпискаСправочников = клиент.Метаданные.Справочники; // Выводим список справочников на экран foreach (dynamic ключЗначение in узелСпискаСправочников) { Console.WriteLine(ключЗначение.Key); } // Получаем узел коллекции реквизитов справочника “Номенклатура” dynamic узелСпискаРеквизитов = клиент.Метаданные.Справочники.Номенклатура.Реквизиты; // Выводим список реквизитов на экран foreach (dynamic ключЗначение in узелСпискаРеквизитов) { Console.WriteLine(ключЗначение.Key); } // Получаем узел коллекции общих модулей dynamic узелСпискаОбщихМодулей = клиент.Метаданные.ОбщиеМодули; // Выводим список общих модулей foreach (dynamic ключЗначение in узелСпискаОбщихМодулей) { Console.WriteLine(ключЗначение.Key); } // Получаем узел коллекции общих модулей dynamic узелДокумента = клиент.Метаданные.Документы.ЗаказКлиента; // Выводим на экран синоним имени документа Console.WriteLine(узелДокумента.Синоним());

Доступ к подчиненному узлу метаданных на требуемой глубине может быть получен также вызовом методов “Найти()” или “ПопыткаНайти()“:

// Получаем узел коллекции реквизитов справочника “Номенклатура” dynamic узелСпискаРеквизитов1 = клиент.Метаданные.Найти(“Справочники.Номенклатура.Реквизиты”); // или то же самое dynamic узелСпискаРеквизитов2 = клиент.Метаданные.Найти(“Справочники”).Найти(“Номенклатура.Реквизиты”); // или то же самое dynamic узелСпискаРеквизитов3 = клиент.Метаданные.Найти(“Справочники”).Найти(“Номенклатура”).Найти(“Реквизиты”); // Получаем реквизиты табличной части “Товары” документа “ЗаказКлиента” dynamic узелСпискаРеквизитов = клиент.Метаданные.Найти(“Документы.ЗаказКлиента.ТабличныеЧасти.Товары.Реквизиты”); УзелМетаданных узел; if (клиент.Метаданные.ПопыткаНайти(“Документы.ЗаказКлиента.ТабличныеЧасти.Товары”, out узел)) { Console.WriteLine(узел.Синоним()); }

Косвенный доступ к метаданным

Обращение к узлам метаданных конфигурации происходит автоматически в следующих случаях:

  • при создании/получении ссылок на объекты;
  • при обращении к контекстным данным ссылок (к реквизитам и табличным частям);
  • при обращении к контекстным данным объектов (к реквизитам и табличным частям);
  • при обращении к общим модулям и модулям менеджеров объектов.

Обращение к узлам метаданных происходит для контроля наличия тех или иных объектов конфигурации, а также для определения их полного состава.

dynamic текСсылка = клиент.Справочники.Номенклатура.НайтиПоНаименованию(“Телевизор”); // Происходит автоматическое обращение к узлам “Справочники” и “Справочники.Номенклатура” // для проверки их существования в данной конфигурации. dynamic текСсылка = клиент.Перечисления.СтавкиНДС.НДС18; // Происходит автоматическое обращение к узлам “Перечисления” и “Перечисления.СтавкиНДС” // для проверки их существования в данной конфигурации, а также для получения // предопределенного значения “НДС18”. dynamic результат = клиент.РаботаСДанными.ПолучитьДанные(); // Происходит автоматическое обращение к узлам “ОбщиеМодули” и “ОбщиеМодули.РаботаСДанными” // для проверки их существования в данной конфигурации.

Загрузка метаданных

При прямом или косвенном обращении к объектам метаданных происходит их автоматическая загрузка с сервера. По этой причине первое обращение к объектам определенного типа сопровождается дополнительными серверными вызовами. Чтобы уменьшить количество таких вызовов, можно заранее загрузить метаданные одним или несколькими запросами.

Для загрузки метаданных необходимо вызвать метод “ЗагрузитьМетаданные()” объекта “БромКлиент” и указать первым параметром список объектов, которые должны быть загружены.

Если требуемых объектов много, то лучше проводить загруку несколькими пакетами. В качестве второго опционального параметра метода можно указать максимальное количество объектов в одном пакете.

Клиентский модуль самостоятельно загрузит метаданные с учетом указанных ограничений.

// Загружаем все объекты метаданных единым блоком (не рекомендуется) клиент.ЗагрузитьМетаданные(“*”); // Загружаем все объекты метаданных пакетами по 100 объектов клиент.ЗагрузитьМетаданные(“*”, 100); // Загружаем только некоторые коллеции метаданных пакетами по 100 объектов клиент.ЗагрузитьМетаданные(“Справочники.*, Документы.*”, 100); // или сокращенно клиент.ЗагрузитьМетаданные(“Справочники, Документы”, 100); // Загружаем только конкретные объекты метаданных клиент.ЗагрузитьМетаданные(“Справочники.Номенклатура, Справочники.Контрагенты, Документы.ЗаказКлиента”);

ВАЖНО!
Метаданные сложных промышленных конфигураций могут содержать десятки и даже сотни мегабайт данных.

По этой причине их передача одним пакетом может занимать длительное время и приводить к возникновению ошибок передачи данных: к превышению допустимого размера сообщений или к превышению времени обработки запросов.

При необходимости загрузки полного дерева метаданных рекомендуется проводить такую загрузку пакетами ограниченного размера, например по 100-250 объектов в пакете.

Кеширование метаданных

Чтобы не загружать метаданные с сервера при каждом запуске приложения, в библиотеке реализованы механизмы кеширования метаданных на стороне клиента. Для использования данного механизма достаточно создать объект, управляющий кешем, и передать его клиенту:

// Кешируем метаданнные в файловой системе клиент.Метаданные.Кеш = new ФайловыйКешМетаданных(@”C:\КешМетаданных”); // Кешируем метаданнные в файловой системе клиент.Метаданные.Кеш = new ФайловыйКешМетаданных(@”C:\КешМетаданных”); // Если необходимо очистить кеш клиент.Метаданные.Кеш.Очистить();

В библиотеке реализован простейший кеш с использованием файловой системы. Чтобы реализовать кеш с использованием других механизмов (например, с использованием базы данных), достаточно создать собественный класс кеша, реализующий интерфейс “ИКешМетаданных“.

ВАЖНО!
Метод ЗагрузитьМетаданные() всегда загружает данные непосредственно с сервера, игнорируя кеш. При этом загруженные данные кешируются, если менеджер кеша был установлен.

Источник: https://brom.itworks.group/documentation/net-core/metadata/

Механизм

1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

В технологической платформе 8.3.11 был введен специальный механизм — «История данных».  Этот механизм видится достаточно полезным, так как предоставляет ту функциональность, которую не редко приходится реализовывать вручную. В этой статье я попробую рассказать о том, что это за механизм, для чего он нужен и как с ним работать.

Начнем с общей теоретической информации о том, что такое история данных и как она устроена.

Описание и возможности

История данных — это механизм позволяющий хранить в базе данных упорядоченные по времени версии объектов конфигурации.

Под версией понимаются данные, которые были в объекте на момент редактирования и состояние метаданных на момент редактирования.

Хранить историю можно как для всего объекта целиком, так и для отдельных реквизитов — имеется возможность тонкой настройки работы механизма для каждого реквизита, в том числе табличные части.

Включать и выключать историю можно как из конфигуратора, так и средствами встроенного языка, все это дает возможность управлять историей для каждого пользователя отдельно.

Само по себе хранение истории достаточно бесполезная функция, поэтому с историей данных можно выполнять следующие операции:

  • записывать версию данных;
  • получать данные определенной версии;
  • удалять данные определенной версии;
  • получать разницу между двумя версиями одного объекта;
  • прочие полезные возможности.

На момент написания статьи (8.3.13) история данных поддерживается для следующих объектов:

  • общие реквизиты;
  • константы;
  • справочники;
  • документы;
  • бизнес-процессы;
  • задачи;
  • регистры сведений;
  • планы обмена;
  • планы счетов;
  • планы видов характеристик;
  • планы видов расчетов;
  • расширения конфигурации.

Работа с историей данных регулируется правами доступа и отражается в журнале регистрации.

Устройство механизма

История данных хранится в специальных таблицах информационной базы. Кроме самих данных в этих таблицах хранятся метаданные прежних версий объектов. Версии метаданных создаются в момент изменения этих самых метаданных у объекта и никак не связаны с изменением данных объекта.

Также следует помнить, что на данный момент система не отличает включение версионирования для реквизита от создания реквизита и отключение версионирования реквизита от удаления реквизита.

Создание версии объекта состоит из двух этапов. Сначала, автоматически или с помощью специального метода, фиксируется факт изменения объекта и информация об этом изменении попадает в очередь.

Перенос данных из очереди в таблицы базы выполняется методом ОбновитьИсторию(), этот метод можно выполнять асинхронно, например регламентным заданием.

Идущие подряд изменения одного объекта не «склеиваются» и фиксируются отдельно, вне зависимости от периодичности обновления истории данных.

Настройка версирования объектов осуществляется либо из конфигуратора либо при помощи встроенного языка.

Конфигуратор логично использовать в тех случаях, когда история данных потребуется во всех режимах работы приложения или на нее завязана какая-то прикладная логика.

Использование встроенного языка потребуется для реализации более гибкой системы, например когда пользователя потребуется самому выбирать для каких объектов хранить историю данных.

Для управления историей данных объектов в конфигураторе реализовано свойство «История данных», оно присутствует как у основных объектов (у справочников, например) так и у подчиненных — реквизиты, табличные части с их реквизитами, ресурсы регистров сведений.

Свойство «История данных»

По умолчанию свойство «История данных» установлено в значение «Использовать» у:

  • стандартных реквизитов;
  • реквизитов объектов;
  • реквизитов табличных частей;
  • измерений регистров сведений (без возможности отключения);
  • ресурсов регистров сведений.

Использование механизма

Для обращения к истории данных используется свойство глобального контекста ИсторияДанных, методы этого этого свойства будут рассмотрены ниже.

Управление использованием истории данных

Ниже приведены примеры того, как, средствами встроенного языка, можно управлять использованием истории данных. Отмечу, что значения свойства ИсторияДанных (полученные «через точку») берутся из конфигуратора и могут не соответствовать действительности, для получения актуальной информации нужно пользоваться методом ПолучитьНастройки().

&НаСервере Процедура УправлениеИспользованиемИсторииДанных() //Получения значения свойства “История данных” //установленного в конфигураторе у объекта ОбъектВключен = Метаданные.Справочники.Справочник1.ИсторияДанных; //у реквизита объекта РеквизитВключен = Метаданные.Справочники.Справочник1.Реквизиты.Найти(“Реквизит1”).ИсторияДанных; //у реквизита табличной части объекта РеквизитТЧВключен = Метаданные.Справочники.Справочник1.ТабличныеЧасти.ТабличнаяЧасть1.Реквизиты.Найти(“Реквизит1”).ИсторияДанных; //у стандартного реквизита объекта СтандартныйРеквизитВключен = Метаданные.Справочники.Справочник1.СтандартныеРеквизиты.Наименование.ИсторияДанных; //Получение информации об изменениях настроек истории данных Настройки = ИсторияДанных.ПолучитьНастройки(Метаданные.Справочники.Справочник1); //Изменение настройки истории данных средствами встроеннго языка Насторойки = Новый НастройкиИсторииДанных; //Настройка для самого объекта Насторойки.Использование = Истина; //Для реквизитов объекта Насторойки.ИспользованиеПолей.Вставить(“Реквизит1”, Ложь); Насторойки.ИспользованиеПолей.Вставить(“ТабличнаяЧасть1.Реквизит1”, Ложь); ИсторияДанных.УстановитьНастройки(Метаданные.Справочники.Справочник1, Насторойки); //Возвращаем настройки истории данных из конфигуратора ИсторияДанных.УстановитьНастройки(Метаданные.Справочники.Справочник1, Неопределено); КонецПроцедуры

Процедура УправлениеИспользованиемИсторииДанных()    //Получения значения свойства “История данных”    //установленного в конфигураторе у объекта    ОбъектВключен = Метаданные.Справочники.Справочник1.ИсторияДанных;    РеквизитВключен = Метаданные.Справочники.Справочник1.Реквизиты.Найти(“Реквизит1”).ИсторияДанных;    //у реквизита табличной части объекта    РеквизитТЧВключен = Метаданные.Справочники.Справочник1.ТабличныеЧасти.ТабличнаяЧасть1.Реквизиты.Найти(“Реквизит1”).ИсторияДанных;    //у стандартного реквизита объекта    СтандартныйРеквизитВключен = Метаданные.Справочники.Справочник1.СтандартныеРеквизиты.Наименование.ИсторияДанных;    //Получение информации об изменениях настроек истории данных    Настройки = ИсторияДанных.ПолучитьНастройки(Метаданные.Справочники.Справочник1);    //Изменение настройки истории данных средствами встроеннго языка    Насторойки = Новый НастройкиИсторииДанных;    //Настройка для самого объекта    Насторойки.Использование = Истина;    Насторойки.ИспользованиеПолей.Вставить(“Реквизит1”, Ложь);    Насторойки.ИспользованиеПолей.Вставить(“ТабличнаяЧасть1.Реквизит1”, Ложь);    ИсторияДанных.УстановитьНастройки(Метаданные.Справочники.Справочник1, Насторойки);    //Возвращаем настройки истории данных из конфигуратора    ИсторияДанных.УстановитьНастройки(Метаданные.Справочники.Справочник1, Неопределено);

Запись версии

Обычно запись версии выполняется автоматически — в два этапа, как описано выше. Но иногда требуется перенести историю данных в системное хранилище из какого-либо другого хранилища. Для этого используется метод ЗаписатьВерсию() и в этом случае данные записываются сразу в таблицы информационной базы, без необходимости обновлять историю.

&НаСервере Процедура ЗаписьВерсииДанных() Данные = Справочники.Справочник1.НайтиПоНаименованию(“Элемент1”).ПолучитьОбъект(); ДатаСоздания = '20180101'; Пользователь = ПользователиИнформационнойБазы.НайтиПоИмени(“Администратор”); ИсторияДанных.ЗаписатьВерсию(Данные, ДатаСоздания, Пользователь.УникальныйИдентификатор, Пользователь.Имя, Пользователь.ПолноеИмя, ВидИзмененияДанных.Добавление, “Тестируем запись версий”); КонецПроцедуры

Процедура ЗаписьВерсииДанных()    Данные = Справочники.Справочник1.НайтиПоНаименованию(“Элемент1”).ПолучитьОбъект();    ДатаСоздания = '20180101';    Пользователь = ПользователиИнформационнойБазы.НайтиПоИмени(“Администратор”);    ИсторияДанных.ЗаписатьВерсию(Данные, ДатаСоздания,         Пользователь.УникальныйИдентификатор, Пользователь.Имя,         Пользователь.ПолноеИмя, ВидИзмененияДанных.Добавление,         “Тестируем запись версий”);

Получение списка версий

Легко представить, что при интенсивной работе пользователей в информационной базе может храниться очень значительное количество версий объектов. Следовательно для анализа истории данных скорее всего потребуется гибкий инструмент позволяющий нужные версии. Таким инструментом выступает метод ВыбратьВерсии(). Этот метод позволяет указать критерии отбора (первый параметр — Отбор).

При заполнении этих критериев следует учитывать некоторые особенности:

  • Необходимо указать один из параметров — Метаданные или Данные, можно указать оба, но только в том случае, когда метаданные параметра Данные совпадают со значением параметра Метаданные;
  • Перед получением версий конкретного объекта рекомендуется выполнить обновление истории по этому объекту — ОбновитьИсторию(СсылкаНаОбъект);
  • Для отбора по пользователю используется идентификатор пользователя, который можно получить с помощью метода УникальныйИдентификатор() объекта ПользовательИнформационнойБазы;
  • Параметр ИзменениеЗначенийПолей позволяет отобрать только те версии в которых изменялись значения указанных полей;
  • Если на значения полей требуется наложить конкретные условия, то поможет параметр ЗначенияПолей.

Полную информацию о доступных параметрах отбора можно найти в синтаксис помощнике.

Получим список версий конкретного объекта, в которых изменялся указанный реквизит.

Источник: https://1c-programmer-blog.ru/programmirovanie/istoriya-dannyh-v-1s.html

1C и ETL

1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

Если вы, как ETL-специалист столкнулись с необходимостью получать данные из 1С, то это первое, что вы можете увидеть, попытавшись разобраться со структурой БД (это из случае MSSQL, для других СУБД картинка аналогичная): Бизнес-смысл в наименованиях таблиц и полей отсутствует, внешних ключей нет.

Пару ласковых о самой 1С. Реальные таблицы СУБД в ней скрыты за объектами, которые видит разработчик, который часто не догадывается о реальной структуре базы. Да… И весь код на русском языке. Кроме того, есть перечисления, строковые представления которых с помощью SQL получить практически невозможно.

Об этом подробнее здесь.

Есть случаи, когда БД нет (и 1С в файловой версии), но это, разумеется ориентирует вас на интеграцию без использования средств СУБД.

Однако, не стоит впадать в отчаяние, поскольку все не так плохо, как кажется.

Внимательный взгляд

Для захвата данных из 1С у вас есть 2 пути:

Реализация «высокоуровневого» интерфейса

Вы можете воспользоваться файловыми выгрузками, web/json сервисами и прочими возможностями 1С, которые окажутся совместимы с вашим ETL. +

  1. Вам не придется лезть в 1С.

    Все, что на стороне 1С должны сделать 1Сники

  2. Вы никак не нарушаете лицензионную политику 1С

  1. Появляется еще один источник для ошибок в виде дополнительных выгрузок-загрузок,
    расписаний, роботизации
  2. Это будет работать существенно медленнее из-за особенностей интерфейсов 1С
  3. При любых изменениях в захватываемых данных, вам придется вносить изменения в выгрузки (но это можно обойти настроечной системой)
  4. Это вызовет больше ошибок в целостности данных, чем работа напрямую с СУБД

Реализация на СУБД

+

  1. Работает быстрее
  2. Позволяет гарантировать полноту данных в хранилище при правильном подходе

  1. Нарушает лицензионное соглашение с 1С

Итак, взвесив за и против, вы решаете строить интеграцию через СУБД, ну или хотя бы подумать, как вы будете это делать дальше.

Data mapping

Для того, чтобы связать бизнес-данные, как их понимают на стороне 1С с реальными таблицами БД, вам потребуется выполнить немного магии в самой 1С, а именно получить описание метаданных 1С в пригодном для использования виде (в связи бизнес-объектов и таблиц).

Опять же есть, как минимум, целых 3 подхода:

  1. Используя com-соединение, web/json сервис получить таблицу соответствия из 1С
  2. Сделать то же самое на стороне 1С, сформировав таблицу метаданных
  3. Разобрать бинарный файл, который хранится в той же БД

3-й путь мне кажется несколько рискованным в силу того, что 1С имеет привычку вносить изменения в свои внутренности без предупреждения. И, при этом, довольно сложным. Выбор между 1 и 2 не столь очевиден, но на мой вкус использовать заранее сформированную таблицу гораздо удобнее, и надежнее в ежедневном использовании и нет нужды задействовать что-то, кроме чистого SQL. Хранить и поддерживать актуальность таблицы удобнее при помощи 1С, обновляя после каждого обновления конфигурации. При этом, ETL может пользоваться View, который покажет данные уже в более удобоваримой форме.

Подготовка таблицы метаданных

Создать в 1С объект, который содержит метаданные конфигурации (к сожалению, скриптом это не сделать, но можно отдать инструкцию 1С-нику) РегистрСведений.СтруктураКонфигурации Поля: ИмяТаблицыХранения ИмяТаблицы СинонимТаблицы Назначение ИмяПоляХранения СинонимПоля Все строки 150 символов Получается денормализованно, но довольно удобно и просто.

Код 1С для заполнения структуры: СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных(,истина);ЗаписиСтруктура = РегистрыСведений.СтруктураКонфигурации.СоздатьНаборЗаписей();Для каждого СтрокаСтруктуры Из СтруктураБД Цикл Для каждого СтрокаПолей Из СтрокаСтруктуры.Поля Цикл Запись = ЗаписиСтруктура.Добавить(); Запись.ИмяТаблицыХранения = СтрокаСтруктуры.

ИмяТаблицыХранения; Запись.ИмяТаблицы = СтрокаСтруктуры.ИмяТаблицы; Запись.СинонимТаблицы = Метаданные.НайтиПоПолномуИмени(СтрокаСтруктуры.Метаданные); Запись.Назначение = СтрокаСтруктуры.Назначение; Запись.ИмяПоляХранения = СтрокаПолей.ИмяПоляХранения; Запись.СинонимПоля = Метаданные.НайтиПоПолномуИмени(СтрокаПолей.Метаданные); КонецЦикла;Конеццикла;ЗаписиСтруктура.

Записать(истина); Опять же все довольно просто и очевидно, несмотря на русский язык. Нужно выполнять этот код при каждом обновлении конфигурации. Делать это можно руками в обработке или при помощи регламентного задания. Таблицу можно просматривать как в режиме клиента, так и со стороны SQL, зная их имена.

SELECT * FROM _InfoReg27083 ORDER BY _Fld27085 (_InfoReg27083 — имя, которое 1С дала таблице регистра со структурой, _Fld27085 — имя поля с именем таблицы хранения) Можно сделать View, чтобы было удобнее.

Если нет возможности вносить изменения в конфигурацию, можно сделать таблицу, соединившись через com, или дописав в обработке выгрузку в таблицу базы, которая задействована в ETL.

А здесь про то, какие есть типы таблиц, и зачем они нужны (нужен доступ к ИТС 1C).

Следующий шаг — составить карту данных и описание трансформации.

Field Field1C Transformation … _Fld15704 Документ.РеализацияТоваровУслуг.Вес Check >=0, round(10,2),… …

Вот мы получили таблицу маппинга, которую можно использовать в дальнейшей работе.

Захват изменений данных

Теперь с точки зрения стратегии захвата изменений данных. Здесь опять есть несколько вариантов. Проще забирать таблицы целиком, что, разумеется может стоить серверу существенных дополнительных расходов. Однако, есть и другие способы:

  1. Использовать версии объектов
  2. Использовать план обмена

Использовать версии объектов

Для объектов «ссылочного» типа 1С поддерживает версии. Номер версии объекта записывается в бинарное поле _version, аккуратно обновляющееся при каждом обновлении записи. На MSSQL, например, это поле типа timestamp. Версии поддерживаются для объектов типа «Документ»,«Справочник»,«Бизнес-процесс»,«Задача»,«План счетов»,«План видов характеристик», «Константы».

Использовать версию довольно просто, сохранив у себя в staging area значение последней версии для объекта, и при следующем обновлении выбрав объекты, большие по значению поля версии. Вместе с «основным» объектом нужно не забыть забрать его табличные части (см.

Назначение — «Табличная часть») в структуре (поле вида _DocumentXXX_IDRRef или _ReferenceXXX_IDRRef — ссылка на основную таблицу).

Использовать план обмена

Для не ссылочных типов такой подход не годится, но можно воспользоваться объектом «план обмена». В таблице структуры их назначение = 'РегистрацияИзменений'. Для каждого объекта конфигурации создается отдельная таблица плана обмена. На уровне БД это таблица, вот такой структуры: _NodeTRef, — идентификатор типа «узла» плана обмена.

Он нам не очень интересен _NodeRRef, — идентификатор узла плана обмена _MessageNo, — номер сообщения Дальше идут поля ключа «основной» таблицы.

Они различаются в зависимости от типа таблицы, с которой связана таблица плана обмена: _IDRRef — в данном случае ID справочника или документа может быть вот так вот: _RecorderTRef _RecorderRRef Это будет таблица изменений регистра накопления, регистра сведений, подчиненного регистратору, или регистра бухгалтерии.

Так же может быть ключ таблицы регистра сведений, если он не подчинен регистратору. Для того, чтобы такая таблица регистрации изменений существовала, нужно включить в конфигураторе 1С нужный нам объект в план обмена. Кроме того, нужен быть создан узел плана обмена, идентификатор (_IDRRef) которого наим нужно будет использовать.

Таблицу плана обмена можно найти в структуре (см. выше). Т.к. в плане обмена регистрируются изменения для всех узлов, а не только для хранилища, нам нужно ограничить выборку нужным нам _NodeRRef. План обмена можно использовать и для ссылочных объектов, но на мой взгляд это бессмысленный расход ресурсов.

Как забирать данные через план обмена: Для начала мы пишем update к плану обмена, где ставим произвольный _MessageNO (лучше всегда 1). Например

UPDATE _DocumentChangeRec18901 set _MessageNO = 1 WHERE _NodeRRef = @_NodeRRef

Далее выбираем данные из таблицы данных, связав ее по ключу с таблицей плана обмена

SELECT [fieldslist] FROM _Document18891 inner join _DocumentChangeRec18901 ON _Document18891._IDRRef = _DocumentChangeRec18901._IDRRef and _MessageNO = 1 AND _NodeRRef = @_NodeRRef

И подтверждаем забор изменений, удалив записи таблицы изменений

DELETE FROM _DocumentChangeRec18901 WHERE _MessageNO = 1 AND _NodeRRef = @_NodeRRef

Итого: Мы научились читать на стороне ETL метаданные 1С, научились выполнять захват данных. Остальные шаги процесса ETL достаточно хорошо известны. Например, можно почитать здесь.

Хабы:

  • Администрирование баз данных
  • Хранилища данных

Источник: https://habr.com/ru/post/334798/

Глава 39 Работа с Метаданными

1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

Глобальный атрибут «Метаданные» является вспомогательным объектом системы, предназначенным для доступа к свойствам структуры метаданных конфигурации.

Возможность доступа к метаданным средствами встроенного языка является дополнительной возможностью и применяется в специальных случаях, например, для создания универсальных отчетов или обработок, которые обращаются к объектам различных видов (документам, справочникам и т. п.). В основных алгоритмах конфигурации данная возможность, как правило, не используется.

Контекст работы с метаданными

Работа с метаданными выполняется через глобальный атрибут «Метаданные», имеющий тип «Метаданные». Объект типа «Метаданные» нельзя создать, используя метод СоздатьОбъект.

Объект типа «Метаданные» имеет атрибуты для доступа к свойствам объекта метаданных и методы для доступа к массивам подчиненных объектов метаданных.

Глобальный атрибут «Метаданные» предоставляет доступ к общим свойствам конфигурации и к основным объектам метаданных (документам, справочникам и т. п.).

Полученный из глобального атрибута подчиненный объект метаданных — документ предоставляет в свою очередь доступ к свойствам документа и к объектам метаданных являющихся реквизитами документа.

Значения, имеющие тип «Метаданные», можно напрямую использовать в качестве параметров в тех методах, где требуется строковый идентификатор метаданного, например, в методе справочника: Вид(НаименовСправочника).

Кроме того, объект типа «Метаданные» можно использовать в качестве параметров, в тех методах, где требуется указать тип данных строкой, например в третий параметр метода ВвестиЗначение(, , , ), но передавать можно только значения метаданных, описывающие типизированные объекты, например, Метаданные.Справочник(1).Реквизит(1), т. к. реквизит справочника — типизированный объект.

Англоязычный синоним ключевого слова Метаданные — Metadata.

Пример:

ВыбМетодУдаления = Метаданные.НепосредедственноеУдалениеОбъектов;

Атрибуты и методы объекта «Метаданные»

В документации не приводится полный перечень возможных значений атрибутов. Полный перечень атрибутов метаданных можно получить, сформировав в конфигураторе текстовый файл «Описание метаданных». Установленные значения атрибутов можно также узнать из текстового описания структуры метаданных.

Атрибуты, являющиеся по сути признаками с двумя возможными значениями имеют числовой тип и принимают значения 0 или 1. Атрибуты, которые могут иметь несколько возможных значений, выдают строку, отражающую установленный вариант. Атрибуты, отражающие свойство метаданных, выбираемое как ссылка на другой объект метаданных (например, журнал документа) имеют тип «Метаданные».

Пример:

ВыбМетодУдаления=Метаданные.НепосредственноеУдалениеОбъектов;

У объекта «Метаданные» могут существовать методы для доступа к массивам подчиненных метаданных. Например, для глобального атрибута «Метаданные» для обращения к документам используется метод «Документ».

В качестве параметра методов для доступа к массивам подчиненных метаданных передается:

·         число — выдает объект метаданных по указанному номеру;

·         строка — выдает объект метаданных по указанному идентификатору;

·         параметр не указан — выдает количество подчиненных объектов этого типа.

Пример получения списка документов конфигурации:

Для Инд = 1 По Метаданные.Документ() Цикл

   Сообщить(Метаданные.Документ(Инд).Идентификатор);

КснецЦикла;

У объекта типа «Метаданные» могут существовать атрибуты, содержащие массив ссылок на объекты метаданных, к ним применяются методы Количество() и Получить(Ном) для перебора ссылок. Например, для граф отбора таким атрибутом является атрибут «Ссылки», позволяющий получить объекты метаданных включенные в данную графу отбора (реквизиты документов и др.).

Пример:

Для Инд = 1 До Метаданные.ГрафаОтбора(Идент).Ссылки.Количество() Цикл

   Сообщить(Метаданные.ГрафаОтбора(Идент).

              Ссылки.Получить(Инд).ПолныйИдентификатор());

КонецЦикла;

Методы работы с метаданными

Перечень методов метаданных предназначенных для доступа к подчиненным объектам метаданных можно получить, сформировав в конфигураторе текстовый файл «Описание структуры метаданных».

Дополнительные методы работы с метаданными приведены ниже.

Выбран

Проверяет спозиционирован ли объект типа «Метаданные» на конкретном объекте метаданных или нет.

Синтаксис:

Выбран()

Англоязычный синоним:

Selected

Возвращаемое значение:

Число: 1 — если объект соответствует объекту метаданных (спозиционирован); 0 — если не соответствует.

Описание:

Метод Выбран возвращает число со значением 1 — объект соответствует объекту метаданных (спозиционирован), 0 — если не соответствует. Например, при обращении к массиву подчиненных метаданных по идентификатору, если метаданного с таким идентификатором не существует, возвращается не спозиционированный объект типа «Метаданные».

Пример:

Если Метаданные.Справочник(“Организации”).Выбран() = 1 Тогда

   Сообщить(“Есть справочник органиазаций”);

КонецЕсли;

Родитель

Возвращает объект метаданных, которому подчинен данный объект.

Синтаксис:

Родитель()

Англоязычный синоним:

Parent

Возвращаемое значение:

Объект метаданных, которому подчинен данный объект.

Описание:

Метод Родитель возвращает объект метаданных, которому подчинен данный объект.

Пример:

Сообцить(“Реквизит принадлежит документу” + РеквМД.Родитель().Идентификатор);

ПолныйИдентификатор

Возвращает полный идентификатор объекта.

Синтаксис:

ПолныйИдентификатор()

Англоязычный синоним:

FullIdentifier

Возвращаемое значение:

Идентификатор объекта с идентификаторами его родителей через точку.

Описание:

Метод ПолныйИдентификатор возвращает идентификатор объекта с идентификаторами его родителей через точку, например: “Документ.Счет.Цена”.

Пример:

Сообщить(“Реквизит ” + РеквМД.ПолныйИдентификатор());

Представление

Возвращает представление объекта.

Синтаксис:

Представление()

Англоязычный синоним:

Present

Возвращаемое значение:

Строковое значение представления объекта.

Описание:

Метод Представление возвращает синоним объекта, а если он не задан, то идентификатор.

Пример:

Получение списка видов документов:

Спис = СоздатьОбъект(“СписокЗначений”);

Для Инд = 1 По Метаданные.Документ() Цикл

   Идент = Метаданные.Документ(Инд).Идентификатор;

   Предст = Метаданные.Документ(Инд).Представление();

   Спис.ДобавитьЗначение(Идент, Предст);

КонецЦикла;

ДлинаПредставленияЗначения

Возвращает длину представления значения.

Синтаксис:

ДлинаПредставленияЗначения(, , )

Англоязычный синоним:

ValuePresentLen

Параметры:

Необязательный параметр. Метод не будет возвращать значение меньше указанной в данном параметре величины.
Необязательный параметр. Метод не будет возвращать значение больше указанной в данном параметре величины.
Необязательный параметр. Метод будет возвращать данную величину для метаданных, для которых длина представления не определена. Параметр задает длину для типов данных, таких как Справочник неопределенного типа и аналогичных, у которых не определена длина.

Возвращаемое значение: возвращает длину представления значения.

Описание:

Метод ДлинаПредставленияЗначения для типизированных объектов типа Реквизит и аналогичных, выдает длину представления значения. Данный метод может использоваться, например, для определения ширины столбца в универсальных отчетах, выводящих данные объектов различных видов.

Пример:

Ширина =

   Метаданные.Документ(1).РеквизитШапки(2).ДлинаПредставленияЗначения(5, 50, 30)


Источник: http://anatoly4xs.narod.ru/manual/lang/lang039.htm

Получение информации о структуре хранения базы данных в терминах 1С:Предприятие и СУБД

1с 8 работа с метаданными. Работа с метаданными. Получение метаданных по полному имени

Часто возникает необходимость определить в какой таблице СУБД хранится тот или иной объект метаданных. Или наоборот, какой объект метаданных соответствует определенной таблице СУБД.

Здесь стоит упомянуть, что имена таблиц и полей СУБД, в которых хранятся объекты метаданных 1С:Предприятия, не соответствуют именам объектов метаданных, их реквизитам, измерениям, ресурсам.

Получение такой информации не представляет особой сложности, тем не менее, если Вы никогда этого не делали, данная статья будет Вам полезна.

Получение структуры хранения базы данных

В целом, эту статью можно было бы изложить в одном коротком предложении: для получения информации о структуре хранения базы данных, а также соответствие имен объектов в терминах 1С:Предприятие и СУБД необходимо воспользоваться методом ПолучитьСтруктуруХраненияБазыДанных(). Но мы пойдем дальше и попробуем разобраться с областью применимости этого метода, а также организуем удобную работу с возвращаемыми методом данными.

Давайте, для начала, посмотрим что же возвращает данный метод. Результатом вычисления данной функции будет таблица значений, в которой каждая строка таблицы определяет одну таблицу СУБД. В первых двух колонках указано имя таблицы в терминах СУБД и в терминах 1С:Предприятия.

Далее идут колонки описывающие к какому метаданному относится таблица и назначение этой таблицы СУБД. Последние две колонки содержат вложенные таблицы значений полей и индексов таблицы СУБД.

В таблице полей содержится соответствие имен полей в терминах СУБД и терминах 1С:Предприятие, а так же связь поля с объектом метаданного (какой реквизит/ресурс/измерение).

Таблица индексов содержит набор имен индексов, а так же вложенную таблицу значений, содержащую поля таблицы СУБД, включенные в состав индекса, и соответствие их имен в терминах СУБД и 1С:Предприятие.

Структура хранения базы данных

Как мы видим, структура, возвращенная методом, включает несколько уровней вложенности и требует создания инструмента для удобного использования.

Мы не будем рассматривать как его сделать, поскольку, эта задача с одной стороны простая, с другой каждый может привнести в нее свои «фишки». Пример такого инструмента (обработки) вы можете найти во вложении к статье.

Ниже приведен скриншот обработки.

Обработка «Структура хранения базы данных»

Область применимости

Давайте попробуем проанализировать ту информацию, которую нам предоставляет платформа с помощью метода ПолучитьСтруктуруХраненияБазыДанных() и сопоставим ее с реальной структурой СУБД (рассмотрим на примере MS SQL Server).

Сразу оговорюсь что метод имеет 2 параметра: первый устанавливает отбор на метаданные по которым необходимо получить информацию; второй устанавливает режим вывода информации: «В терминах СУБД» или «В терминах 1С:Предприятие» (данная опция так же присутствует в обработке).

Представленный ниже текст относится к режиму вывода «В терминах 1С:Предприятие» если не указано иного.

Подготовка базы

Давайте создадим пустую информационную базу в режиме совместимости с 8.2.16, основной режим запуска установим «обычное приложение». В конфигурацию добавим 2 документа (со значениями по умолчанию) и регистр сведений «АнализСтруктурыХранения» (периодичность в пределах дня). У регистра добавим реквизиты:

  1. «Число»: тип число
  2. «Строка»: тип строка
  3. «ДокументСсылка»: тип ДокументСсылка1
  4. «СоставнойЧислоСтрока»: составной тип Число и Строка
  5. «СоставнойДокументСсылка»: составной тип ДокументСсылка1 и ДокументСсылка2
  6. «СоставнойЧислоСтрокаДокументСсылки»: составной тип Число, Строка, ДокументСсылка1, ДокументСсылка2

Далее добавим общий реквизит «Разделитель» (тип Число), в состав включим наши документы и регистр сведений. Установим «Разделение данных» в «разделять» и разрешим создать параметры сеансов, «Использование разделяемых данных» установим в значение «независимо и совместно». Обновим конфигурацию.

Набор таблиц базы данных в СУБД и методе платформы

Откроем обработку в 1С:Предприятие, а также откроем список таблиц базы данных в СУБД и сравним их. Как видно, метод ПолучитьСтруктуруХраненияБазыДанных() вернул не полный список таблиц базы, который мы можем увидеть на уровне СУБД, а набор таблиц за исключением системных таблиц, таких как Config, ConfigSave, v8users и другие.

Структура базы данных на уровне СУБД и платформы

Набор полей (колонок) в таблице

Перейдем теперь к нашему регистру сведений. Получим набор полей таблицы регистра с помощью обработки, а так же получим набор колонок в СУБД и сравним их.

Как видно, для не составных типов (вне зависимости от типа) в СУБД используется 1 колонка таблицы, структура хранения 1С:Предприятия отражает аналогичную информацию.

Если же мы перейдем к полям составного типа, то в обработке все так же выводится информация только об 1 поле, как мы его и задавали в конфигурации, а в СУБД это поле хранится в нескольких колонках и их количество может быть различно в зависимости от состава типа поля, определенного в конфигурации.

Это связано со способом хранения информации платформой и более подробно можно прочесть на сайте ИТС. Замечу, что при анализе запроса в СУБД или анализе плана запроса необходимо учитывать этот факт и правильно интерпретировать имена колонок.
Структура полей (колонок) в таблице базы данных

Состав индексов

Проведем аналогичное сравнение индексов и их состава, полученных обработкой и реально существующих в СУБД. Первое что бросается в глаза, это 12 индексов в таблице СУБД, в то время как обработка выводит только 2.

По своей сути все верно, если индексы разделить по «назначению» («ByDims» — по измерениям, и «ByPeriod» — по периоду).

Размножение произошло по причине того что в составных типах включено более 1 примитивного типа или примитивный тип включен вместе с ссылочным — в этом случае платформа создает для каждой комбинации свой индекс.

Так, в нашем примере реквизит «СоставнойЧислоСтрока» включает 2 примитивных типа, а «СоставнойЧислоСтрокаДокументСсылки» включает 2 примитивных типа и ссылочные (их количество не важно, важно наличие хотя бы одного). Таким образом, платформа создала комбинации индексов: ЧислоЧисло, ЧислоСтрока, ЧислоСсылка, СтрокаЧисло, СтрокаСтрока, СтрокаСсылка.

Откроем состав одного из индексов и сопоставим поля. Как видно, в СУБД первым полем индекса стоит «Fld12», (по таблице полей можно определить что это «Разделитель«) и оно отсутствует составе индекса, выведенного в обработке.

Структура и состав индексов на уровне СУБД и платформы

Продолжаем эксперименты

Давайте продолжим наши эксперименты и (в исследовательских целях) нарушим лицензионное соглашение. Для того чтобы быть уверенными что не сломаем нашу базу данных, сделаем ее резервное копирование средствами СУБД.

Сделаем следующие вещи:

  1. Откроем в СУБД индекс «ByDocNum» объекта Документ1 и поменяем порядок следования полей Number и IDRRef
  2. Удалим в СУБД индекс «ByDocDate» объекта Документ1
  3. Добавим в СУБД колонку, например, «MyColumn» с числовым типом в таблицу регистра сведений
  4. Добавим в СУБД в нашу базу данных новую таблицу, например, «MyTable»

Откроем нашу обработку и проверим что получилось:

  1. Платформа не знает о том что порядок полей в индексе был изменен
  2. Платформа не знает о том что индекс удален
  3. Платформа не видит добавленную колонку
  4. Платформа не видит добавленную таблицу

Задание для самостоятельной работы

Как ранее было сказано, вышеприведенное исследование выполнено для режима «В терминах 1С:Предприятие». Предлагаю проделать всю вышеприведенную работу для режима «В терминах СУБД» самостоятельно и сделать соответствующие выводы. Оговорюсь лишь о том, что большая часть расхождений между реальной структурой в СУБД и структурой возвращенной методом платформы — исчезают.

Выводы

Метод ПолучитьСтруктуруХраненияБазыДанных() предоставляет достаточно полную и корректную информацию о структуре хранения базы данных, а так же выводит соответствия имен таблиц, их колонок, и индексов в терминах СУБД и 1С:Предприятие. Но, при этом есть некоторые ограничения при работе с этим методом:

  1. Нет информации о системных таблицах (но она особо и не нужна)
  2. Состав полей отражается с точки зрения 1С, а не с точки зрения хранения в СУБД (только в терминах 1С:Предприятие)
  3. Набор индексов так же отражается с точки хранения 1С, а не с точки зрения СУБД (только в терминах 1С:Предприятие)
  4. Некоторые существующие поля индекса могут быть не отражены в составе индекса на уровне платформы (только в терминах 1С:Предприятие)
  5. Информация, видимо, строится не по структуре базы данных, а по некому представлению платформы о структуре базы на основании метаданных конфигурации и их свойств
  6. Необходимо иметь ввиду что механизм работы метода может быть изменен в другой версии платформы

Таким образом, если необходимо получить точную информацию о структуре базы данных, необходимо получать эту информацию с помощью СУБД, а при получении данных методом ПолучитьСтруктуруХраненияБазыДанных() лучше использовать режим «В терминах СУБД»

Источник: https://ausevich.ru/ekspert/poluchenie-informatsii-o-strukture-khraneniya-bazy-dannykh-v-terminakh-1s-predpriyatie-i-subd/

Юрист ответит
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: