Механизм истории данных существует уже не первый год. Не буду перечислять его преимущества и недостатки, а остановлюсь на проблемах, с которыми столкнулась в процессе и по результатам перехода.
1. Перенос существующих версий БПС в историю данных
Что привело к проблеме: большой объем переносимых данных, перенос не по порядку периода версий.
В нашей компании активно использовался механизм версионирования БСП, и при переходе на историю данных было принято решение о сохранении накопленных данных. Изначально решили перенести данные за последние 3 месяца. Однако после перехода все-таки потребовалось продублировать историю полностью. Сама по себе процедура переноса работе не мешала, но по некоторым объектам получилась ситуация, когда порядок версий по периоду не соответствовал порядку номеров версий.
Казалось бы, проблема не критичная – исходные номера версий фиксировались в комментарии, а сортировку по дате можно при желании реализовать в существующей форме «История изменений истории данных», но при тестировании удаления версий с «истекшим сроком годности» выяснилось, что удаление версий до даты работает скорее от номера версии, чем от даты удаления.
Воспроизведу пример на базе конфигурации «Демо БСП»
История объекта до удаления:
Выполнен метод:
ИсторияДанных.УдалитьВерсии(ОбъектМетаданных, ГраницаУдаления);
Где
ОбъектМетаданных = Метаданные.Справочники._ДемоКонтрагенты
ГраницаУдаления = 01.01.2015
Результат выполнения
Ожидала, что будут удалены версии с 6 по 8, но похоже, что удаление происходит по номерам версий. То есть складывается впечатление, что метод получает номер первой версии, которая не попадает в указанный период (или последнюю, которая попадает) и удаляет все версии с номерами меньше найденной.
Эта проблема у нас осталась нерешенной – от удаления отказались.
2. Использование расширений и новые реквизиты объекта
В процессе работы обратила внимание на то, что для некоторых объектов метаданных, по которым включена история данных, в данные версии не попадают значения реквизитов, добавленных после включения истории. Происходило это не для всех объектов, большинство работало так, как заявлено в документации.
В первую очередь были проверены настройки объекта на предмет включения новых реквизитов в историю и новые реквизиты отражались там как включенные. А вот в результате выполнения метода
ИсторияДанных.ПолучитьМетаданные();
в структуре возвращаемых полей нужного реквизита не было. После череды проверок с анализом таблицы СУБД _DataHistoryMetadata удалось выяснить следующее:
В случае, когда для объекта включена история данных, объект добавлен в расширение (в нашем случае в расширение не добавлялись реквизиты объекта) и по этому объекту добавляется реквизит в основной конфигурации, этот реквизит может не попасть в структуру метаданных истории данных и будет отсутствовать в версии данных.
Единоразово может помочь отключение/включение хранение истории, но последующие добавляемые реквизиты в метаданные истории не попадут.
Проблему получилось воспроизвести на платформе 8.3.27.1719 в демонстрационной конфигурации БСП. Ошибка была зарегистрирована 1С (bugboard.1c, 60027282.)
Про анализ таблицы _DataHistoryMetadata расскажу немного подробнее.
В этой таблице хранятся метаданные истории данных. Согласно документации версия метаданных для объекта создается в момент изменения структуры метаданных объекта (например, добавление реквизита), метаданные прежних версий так же сохраняются.
Для начала посмотрим, как выглядит таблица при отсутствии расширений. Возьму справочник, по которому ранее история данных не велась и включу настройку в режиме 1С предприятия (Буду работать со справочником «Ставки НДС»). В целевой таблице появится запись следующего вида:
_IsSettings – указывает, что версия метаданных сформирована при изменении настроек
_IsActual – указывает, что версия метаданных является актуальной
_MetadataVersionNumber – Номер актуальной версии метаданных в нашем случае равен 1 (история была включена впервые)
_IsExtensions - признак доработки объекта в расширении
Теперь добавим реквизит в этот справочник, и посмотрим, что произойдет в таблице.
В журнале регистрации помимо информации об изменении объекта будет зафиксирована информация об изменении таблицы метаданных истории данных:
В самой таблице метаданных истории появилась новая запись, для которой _MetadataVersionNumber стал «2», _IsActual – истина. А для первой версии _IsActual отключился
То же самое произойдет, если мы добавим еще один реквизит или непустую табличную часть – будет добавлена новая строка с новым номером версии метаданных и установленным признаком _IsActual. Для предыдущей версии _IsActual будет отключен
При отключении хранения истории в режиме 1С:Предприятие _IsActual отключается
При повторном включении происходит то же, что при добавлении нового реквизита
Теперь воспроизведу ситуацию, которая приводит к неожиданному поведению системы.
Справочник «Виды цен» добавляю в расширение (добавляю только модуль менеджера)
Включаю историю данных. Таблица метаданных истории данных выглядит так же, как и в начале предыдущего примера, но здесь включен флаг _IsExtensions. По идее это не противоречит истине, так как объект действительно включен в расширение.
Добавляю реквизит в конфигурацию. В журнале регистрации вижу, что был изменен сам объект и таблица метаданных истории данных.
Выполняю запрос к _DataHistoryMetadata и вижу, что никаких изменений не произошло
Получается, что новая версия метаданных в таблице не зарегистрировалась. Что подтверждается при формировании версии данных – новый реквизит там так же отсутствует.
Пробую отключить/включить хранение истории объекта в режиме 1С: Предприятие
При отключении ожидаю, что _IsActual будет отключен, но этого не происходит
При включении добавляется строка с новым номером версии, но в отличии от предыдущего эксперимента, _IsActual остается включенным у обеих строк
Тем не менее, добавленный ранее реквизит появляется в новых версиях.
При повторении добавления реквизита происходит то же самое – не добавляется строка в целевой таблице и в данных версии нового реквизита нет. И в этот раз включение/отключение настроек уже не спасает. Несмотря на то, что добавляется новая строка с новым номером версии метаданных, в версии данных объекта нового реквизита нет.
Для решения проблемы пользуемся методом, который крайне не рекомендуется при работе с 1С – вносим изменения в _DataHistoryMetadata прямым запросом SQL, который устанавливает значение поля _IsActual = 0х00 для всех версий, кроме самых последних.
Вариант не самый лучший, но другого не нашли.
3. Использование метода СформироватьПоВерсии()
Согласно документации метод позволяет сразу получить объект данных требуемой версии по его ссылке или ключу записи, но если в версии объекта, по которой производим формирование, отсутствие реквизит или табличная часть, имеющиеся в текущей ссылке, то они будут заполнены данными этой ссылки. Аналогично ведет себя команда «Перейти на версию». В этом есть определенный смысл, например, при появлении реквизита, обязательного к заполнению, но в некоторых случаях может привести к искажению данных.
Вот, пожалуй, и все моменты, на которые хотелось бы обратить внимание.
Полезные статьи по теме:
Вступайте в нашу телеграмм-группу Инфостарт