Версионирование объектов VS История данных

Содержание:

Почему я решил написать данную статью?

Как работает ВО?

Запись

Удаление

Как работает ИД?

Объекты использования

[Киллер-фича №0]

Таблицы в СУБД

Программное включение, проверка и сброс настроек ИД

[Киллер-фича №1]

[Баг №1]

Создание версий. Изменение объекта, выборка изменений и переход на версию

[Киллер-фича №2]

[Киллер-фича №3]

Восстановление удаленного объекта

[Киллер-фича №4]

Тонкость с общими реквизитами и регистрами сведений

Особенность для плана счетов

[Баг или фича?]

Особенность записи версии (перевод с авто на ручной режим) [upd 11.05.2023]

[Баг или фича?]

Ошибка ПриЗаписи(). Вылечили в платформе 8.3.24.1020 [upd 19.06.2023]

Обработка после записи версии истории данных

Таблицы, содержащие ExtX1

Кратко о ИД

Схема работы ИД

Выводы

По ходу экспериментов попытаюсь ответить на вопросы, как работает механизм «История данных», но если эксперименты вам неинтересны, тогда можно сразу перейти к пункту «Кратко о ИД», правда лучше еще посмотреть пункты «Тонкость с общими реквизитами и регистрами сведений», «Обработка после записи версии истории данных», «Особенность для плана счетов».

Как работает ИД?

Вот тут остановимся поподробнее, рассмотрим в примерах.

ИД работает по следующим объектам:

1. Общие реквизиты;

[Включено автоматически и программно менять нельзя]

2. Константы; [с версии "8.3.13"]
3. Планы обмена; [с версии "8.3.13"]
4. Справочники;
5. Документы;
6. Планы видов характеристик; [с версии "8.3.12"]
7. Планы счетов; [с версии "8.3.12"]
8. Планы видов расчета; [с версии "8.3.13"]
9. Бизнес-процессы;
10. Задачи;
11. Регистры сведений.

[Измерения включены по умолчанию и выключать их нельзя]

Киллер-фича №0: ИД может хранить историю по регистрам сведений. ВО так не умеет.

Таблицы в СУБД:

_DataHistoryMetadata – Метаданные истории данных

_DataHistorySettings – Настройки истории данных

_DataHistoryQueue0 – Очередь истории данных

_DataHistoryLatestVersions, _DataHistoryLatestVersions1, _DataHistoryLatestVersions2 – Последние версии истории данных

_DataHistoryVersions – Версия истории данных

_DataHistoryAfterWriteQueue – Очередь обработки после записи истории данных.

[Появилась в версии 8.3.15. Если стоит версия совместимости меньше 8.3.15, тогда данной таблицы в СУБД не будет]

Данные таблицы реализованы для объектов, созданных в расширении:

_DataHistoryMetadataExtX1 – Метаданные истории данных

_DataHistorySettingsExtX1 – Настройки истории данных

_DataHistoryVersionsExtX1 – Версия истории данных

_DataHistoryLatestVerExtX1 – Последние версии истории данных

Давайте перейдем к экспериментам в ходе которых появятся ответы как работает ИД. 

Подготовительные действия:

Скачал БСП 3.1.7.306 и развернул демо базу.

В MSSQL почистил регистр с версиями.

Код:

TRUNCATE TABLE [_InfoRg429]

В MSSQL написал небольшой запрос, который будет выводить по регистру ВО и всем служебным таблицам ИД следующие данные:

• rows - количество строк(записей) в таблице,
• reserved - количество килобайт, забронированное данной таблицей,
• data - количество килобайт, используемое данными,
• index_size - количество килобайт, используемое индексами,
• unused - количество килобайт, забронированное таблицей, но пока данное пространство не заполнено данными.

Код:

USE BSP_DEMO
go 
sp_spaceused [_InfoRg429]
go 
sp_spaceused [_DataHistoryLatestVersions]
go 
sp_spaceused [_DataHistoryLatestVersions1]
go 
sp_spaceused [_DataHistoryLatestVersions2]
go 
sp_spaceused [_DataHistoryMetadata]
go 
sp_spaceused [_DataHistoryQueue0]
go 
sp_spaceused [_DataHistorySettings]
go 
sp_spaceused [_DataHistoryVersions]
go 
sp_spaceused [_DataHistoryAfterWriteQueue]

Где BSP_DEMO – название базы данных.

Программное включение, проверка и сброс настроек ИД

Выключаем версионирование по всем объектам кроме документа «_ДемоПоступлениеТоваров»

Админстрирование/Общие настройки/История изменений/Настроить

Проверяем, что ИД в конфигураторе по документу «ДемоПоступлениеТоваров» выключено.

Видим, что история данных стоит «Не использовать»

Включаем программно ИД для документа «_ДемоПоступлениеТоваров»:

Настройки = Новый НастройкиИсторииДанных;
Настройки.Использование = Истина;	
ИсторияДанных.УстановитьНастройки(Метаданные.Документы._ДемоПоступлениеТоваров, Настройки);

Можно воспользоваться бесплатной обработкой Настройка состава "Истории данных"

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

В таблице [_DataHistoryMetadata]:

В колонке [_Content] содержится метаданные документа «_ДемоПоступлениеТоваров», в случае изменения метаданных будут создаваться новые версии метаданных.

В таблице [_DataHistorySettings]:

В колонке [_Content] хранятся настройки на основании которых будут собираться версии ИД.

Программные настройки можно прочитать следующим кодом:

Настройки = ИсторияДанных.ПолучитьНастройки(Метаданные.Документы._ДемоПоступлениеТоваров);

Если Настройки = Неопределено, значит программные настройки у объекта отсутствуют.

Давайте очистим программные настройки и посмотрим, что поменялось.

Программные настройки можно очистить следующим кодом:

ИсторияДанных.УстановитьНастройки(Метаданные.Документы._ДемоПоступлениеТоваров, Неопределено);

Я воспользуюсь обработкой Настройка состава "Истории данных"

В таблице [_DataHistoryMetadata] изменилась актуальность:

Таблица [_DataHistorySettings] стала пустой:

Таким образом мы получили подтверждение того, что программные настройки для ИД хранятся в [_DataHistorySettings]

Для продолжения экспериментов я опять включу ИД по документу «_ДемоПоступлениеТоваров»

Мы ничего не меняли, просто включили, очистили и повторно включили ИД по документу «_ДемоПоступлениеТоваров», но теперь у нас в таблице [_DataHistoryMetadata] две одинаковые версии метаданных.

Доказательство. Сделаем группировку по метаданным и содержимому:

[Баг №1] Мы нащупали узкое место. Я считаю это недоработкой, так как можно написать обработку, которая будет включать, менять или очищать настройки ИД до тех пор, пока база не съест все пространство. По-хорошему настройка метаданных должны сравниваться с предыдущей версией и если они идентичны тогда в предыдущей настройки метаданных менять статус на актуальную, не создавая новую запись.

Перед включением или выключением ИД убедитесь в том, что оно вам точно нужно

Киллер-фича №1: ИД настраивается программно. ВО первоначально настраивается в конфигураторе. ИД имеет возможность тонкой настройки, ВО настраивается на объект целиком.

Создание версий. Изменение объекта и переход на версию.

Перед следующими экспериментами я почищу таблицы истории данных и программно включу ИД у документа «_ДемоПоступлениеТоваров»:

Давайте создадим версию в ВО и ИД:

Просто запишем документ из демо базы.

Появилась запись в регистре версий [_InfoRg429]:

В таблице, отвечающей за очередью [_DataHistoryQueue0] появилась запись:

В ИД версия формируется не сразу, сначала данные о версии поступают в очередь истории данных [_DataHistoryQueue0]. Для создания версий нужно выполнить код, либо в конфигураторе должна стоять галка «Обновлять историю данных после записи».

Выполним код создания версий:

ИсторияДанных.ОбновитьИсторию();

Примечание: В этот момент в одной из таблиц «DataHistoryLatestVersions» создается последняя версия данных затирая предыдущую, а в таблице «DataHistoryVersions» записывается разносное действие. Это важно понимать особенно когда споры идут про размер данных. Когда вы удаляете версии, вы удаляете действия из таблицы «DataHistoryVersions»

Запись в [_DataHistoryQueue0] исчезла:

Появилась запись в [_DataHistoryLatestVersions1]:

Эта таблица хранит последнюю версию объекта.

Появилась запись в [_DataHistoryVersions]:

На данном этапе версии в таблицах [_DataHistoryLatestVersions1] и [_DataHistoryVersions] равны.

Теперь в документе передвину строку вверх и создам версию:

В [_DataHistoryVersions] добавилась запись:

В [_DataHistoryLatestVersions1] была записана последняя версия:

Я сравнивал содержимое контента таблицы [_DataHistoryLatestVersions1] с предыдущей версией, различие было в 2 небольших фрагментах.

Фрагмент добавлен:

Фрагмент удален:

Обратите внимание удаленный и добавленный фрагмент между собой схожи:

Вывод: Этот фрагмент и есть строка таблицы. Это доказывает, что таблицы [_DataHistoryLatestVersions], [_DataHistoryLatestVersions1] и [_DataHistoryLatestVersions2] созданы для хранения именно последней версии, а таблица [_DataHistoryVersions] хранит отличия.

Теперь в конфигураторе добавлю реквизит у документа, сохраню изменения и создам версию.

Запишу в реквизит «1» и создам версию:

Появилась новая версия метаданных:

В таблице [_DataHistoryVersions] версия записалась уже для новой версии метаданных:

Добавлю реквизит в расширение, сохраню изменения и создам версию:

Запишу в реквизиты «ВКонфигураторе» и «ВРасширении» значение «2»:

В таблице [_DataHistoryMetadata] появилась новая версия метаданных:

[_IsExtensions] = 0x01 [Признак того, что метаданные изменены в расширении]

МетаданныеВерсии = ИсторияДанных.ПолучитьМетаданные(Данные, НомерВерсии);

В таблице [_DataHistoryVersions] версия записалась уже для новой версии метаданных:

На текущий момент мы создали 4 версии, давайте их посмотрим.

[Недоработки] Вот тут мы сразу попадаем в неловкий момент…

Два абсолютно одинаковых пункта меню. Один из них ВО, а другой ИД.

История изменений ВО:

Сравним 4 и 1 версию в ВО:

История изменений ИД:

Как мы видим функционал ИД побогаче, тут есть отборы.

Обратите внимание в отборе можно указать «Удаление».

Киллер-фича №2: ИД хранит версии удаленных объектов из коробки. Для ВО такого не реализовано, я делал отдельную подсистему на основании ВО чтобы реализовать данную возможность -> Нестандартные подсистемы: Живая вода

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

Код удаления версий:

ИсторияДанных.УдалитьВерсии(Данные, НомерВерсииНачала, НомерВерсииКонца);

Сравним 4 и 1 версию в ИД:

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

Давайте получим сравнение версий для документа из ИД кодом:

РазличияВерсий = ИсторияДанных.ПолучитьРазличияВерсий(Документ, НомерВерсииПослеИзменения, НомерВерсииДоИзменения);

Сравнение 1 и 4 версии:

Одной строчкой кода мы получаем разницу версий, при этом изменения разделены на те, что «В конфигураторе» и те, что в «Расширении». Быстро и удобно.

Давайте попробуем перейти на 1 версию при помощи ВО:

Я напомню первая версия у нас была создана без добавленных реквизитов «ВКонфигураторе» и «ВРасширении».

УВЫ и АХ! ВО не смогла.

Пробуем перейти на 1 версию при помощи ИД:

Сложностей не возникло:

В первой версии у нас не было реквизитов поэтому их значение осталось из 4 версии.

Киллер-фича №3: ИД работает от изменений и сопоставление идет по названию полей, поэтому переход на версию проходит в независимости от структуры. ВО жестко привязана к структуре.

Восстановление удаленного объекта.

Давайте удалим документ и попробуем его восстановить при помощи ИД:

В ВО все версии были почищены, можно, конечно, поправить подписку, которая чистит версии и тогда версии останутся, но это уже доработка.

В таблице [_DataHistoryVersions] появилась версия:

[_ChangeType] = 2 [Означает, что данная версия хранит факт удаления]

Вообще восстановление версии делается одной строкой… Но для понимания, давайте сделаем в 3 шага.

1 Шаг. Получим удаленные версии.

Допустим мы знаем уникальный идентификатор удаленного объекта [b2b5373e-6f42-11e4-9b9b-20cf30c960a0].

Получаем битую ссылку:

БитаяСсылка = XMLЗначение(Тип("ДокументСсылка._ДемоПоступлениеТоваров"), "b2b5373e-6f42-11e4-9b9b-20cf30c960a0");

Далее нам надо получить все удаленные версии:

Отбор = Новый Структура;
Отбор.Вставить("Метаданные", Метаданные.Документы._ДемоПоступлениеТоваров);   
Отбор.Вставить("ВидИзмененияДанных", ВидИзмененияДанных.Удаление);
Отбор.Вставить("Данные", БитаяСсылка);
Версии = ИсторияДанных.ВыбратьВерсии(Отбор,,,);

Мы получили таблицу значений с версиями. Видим, что 7 версия с видом «удаление». Нам нужно получить ту версию, на которую мы можем перейти.

Подойдет ли нам версия 7?

Нет, версия 7 не подойдёт, она не содержит данных.

2 Шаг. Получим данные версии идущей перед удаленной:

// Берем версию перед удалением 
НомерВерсии = Версии[0].НомерВерсии - 1;
ДанныеВерсии = ИсторияДанных.ПолучитьДанныеВерсии(БитаяСсылка, НомерВерсии);

Мы видим, что версия заполнена и нас устраивает.

3 Шаг. Восстановим данные по версии, идущей перед удаленной.

Давайте только попробуем сразу записать версию без запуска «ИсторияДанных.ОбновитьИсторию()»:

// Если данные есть восстанавливаем
Если ДанныеВерсии <> Неопределено Тогда  
	// Получаем объект по версии
	ВосстановленныйОбъект = ИсторияДанных.СформироватьПоВерсии(БитаяСсылка, НомерВерсии); 
	
	// отключаем стандартные проверки [Необязательно]
	ВосстановленныйОбъект.ОбменДанными.Загрузка = Истина; 
	
	// Сразу записываем версию вместо «ИсторияДанных.ОбновитьИсторию()» [Необязательно]
	ВосстановленныйОбъект.ЗаписьИсторииДанных.ОбновлятьИсториюСразуПослеЗаписи = Истина;
	
	ВосстановленныйОбъект.Записать();
КонецЕсли;

Мы программно включили при записи объекта выключенное в конфигураторе свойство: 

ВосстановленныйОбъект.ЗаписьИсторииДанных.ОбновлятьИсториюСразуПослеЗаписи = Истина;

Проверяем:

Что у нас в таблице [_DataHistoryVersions]:

[_ChangeType] = 0 [Означает, что данная версия была добавлена]

Теперь мы знаем, что статусы в отборе соответствуют полю [_ChangeType] из таблицы [_DataHistoryVersions].

[_ChangeType] = 0 [Добавление]

[_ChangeType] = 1 [Изменение]

[_ChangeType] = 2 [Удаление]

Киллер-фича №4: ИД из коробки умеет восстанавливать удаленный объект. ВО такое без доработки не может.

Тонкость с общими реквизитами и регистрами сведений

Общие реквизиты;

При попытке программно установить ИД у общих реквизитов вы увидите вот такую ошибку:

…

Регистры сведений.

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

Программно менять можно.

Особенность для плана счетов

У «ПлановСчетов» есть «ПризнакиУчета» и «ПризнакиУчетаСубконто», их имена могут совпадать.

В конфигураторе у нас есть возможность включать\выключать ИД в разрезе «ПризнакиУчета» и «ПризнакиУчетаСубконто».

Пример из ERP:

Было:

Стало:

Когда мы настраиваем ИД программно у нас нет возможности управлять в разрезе «ПризнакиУчета» и «ПризнакиУчетаСубконто».

Не рабочий код:

Настройки = Новый НастройкиИсторииДанных;

Настройки.Использование = Истина;

// специально указан "ПризнакиУчета.Валютный" для демонстрации ошибки
Настройки.ИспользованиеПолей.Вставить("ПризнакиУчета.Валютный", Ложь);

ИсторияДанных.УстановитьНастройки(Метаданные.ПланыСчетов.Международный, Настройки);

Рабочий код:

Настройки = Новый НастройкиИсторииДанных;

Настройки.Использование = Истина;

Настройки.ИспользованиеПолей.Вставить("Валютный", Ложь);

ИсторияДанных.УстановитьНастройки(Метаданные.ПланыСчетов.Международный, Настройки);

Таким образом мы установили ключ = «Валютный» в ложь сразу для «ПризнакиУчета» и «ПризнакиУчетаСубконто».

Проверим настройки:

НастройкиИД = ИсторияДанных.ПолучитьНастройки(Метаданные.ПланыСчетов.Международный);

[Баг или фича?] Не знаю баг это или фича, но я считаю это не доработкой.

Особенность записи версии.

Нам нужно делать версии в «Истории данных», но мы не хотим, чтобы это было в автоматическом режиме, хотим ручной режим.

Что делать?

Все мы использовали Планы обмена и знаем, что там есть автоматическая регистрация и возможность ее отключения:

Но в Истории данных у нас такой механизм отсутствует. Мы можем только использовать и не использовать ИД.

При попытке создать версию вручную по объекту с выключенной ИД мы получим ошибку.

Пример:

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

Получим ошибку:

Переводим создание ИД на ручной режим.

Включаем в конфигураторе ИД:

Программно отключаем историю данных:

И теперь повторяем создание версии:

Проверяем:

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

Ошибка ПриЗаписи(). Вылечили в платформе 8.3.24.1020

Подробнее в статье: История данных. Изменения в платформе 8.3.24

Обработка после записи версии истории данных.

Платформа предоставляет возможность выполнять действия, которые должны происходить только после того, как объект зафиксирован в истории данных. Когда версия записана после ИсторияДанных.ОбновитьИсторию() она попадает в очередь пост обработки [_DataHistoryAfterWriteQueue].

Данный функционал доступен с версии 8.3.15, поэтому, если режим совместимости ниже, в СУБД таблица [_DataHistoryAfterWriteQueue] будет отсутствовать.

Включаю режим совместимости 8.3.15 и выставляю галочку «Выполнять обработку после записи версии истории данных» по справочнику «_ДемоФизическиеЛица»

В модуле менеджера должна быть добавлена процедура «ОбработкаПослеЗаписиВерсийИсторииДанных», я добавил ее в расширении.

После чего зайдем и запишем любой элемент справочника «_ДемоФизическиеЛица».

Выполним в SQL запрос:

USE BSP_DEMO
go 
sp_spaceused [_DataHistoryAfterWriteQueue]

Результат в MSSQL:

Теперь необходимо вызвать обработчик:

ИсторияДанных.ВыполнитьОбработкуПослеЗаписиВерсий(Справочник);

Очень важно! Из [_DataHistoryAfterWriteQueue] запись сама по себе не исчезнет.

Чтобы удалить из пост очереди запись, выполняем код:

ИсторияДанных.УдалитьИзОбработкиПослеЗаписиВерсий(Справочник);

Таблицы, содержащие ExtX1

Добавляем в расширение новый справочник «_ДемоСправочник1» и включаем у него все что связано с ИД:

Результат в MSSQL:

Программно сниму ИД у стандартного реквизита «Ссылка»:

Записываем данные:

Что произойдет если удалить объект из расширения, по которому была включена ИД?

Результат в MSSQL:

При удалении объекта из расширения чистятся и все его следы из таблиц ИД.

Кратко о ИД

1 Если в конфигураторе или программно включена ИД тогда при изменении объекта происходит запись измененной структуры метаданных в таблицу [_DataHistoryMetadata]

Поля [_DataHistoryMetadata]:

_issettings – признак присутствия программных настроек

_isactual – признак актуальности версии метаданных

_isextensions – признак доработки объекта в расширении

_metadataversionnumber – версия метаданных

_content – структура метаданных по объекту

_metadataid – идентификатор объекта

Получить метаданные версии:

ПолучитьМетаданные(<Данные>, <НомерВерсии>)

Получить актуальные метаданные:

ПолучитьМетаданные(<Метаданные>)

2 Программные настройки хранятся в таблице [_DataHistorySettings]

Поля [_DataHistorySettings]:

_content – программные настройки

_metadataid – идентификатор объекта

Получаем настройки:

ПолучитьНастройки(<Метаданные>)

Меняем и удаляем настройки:

УстановитьНастройки(<Метаданные>, <Настройки>)

3 Если в конфигураторе не установлена галка «Обновлять историю данных сразу после записи» или при записи объекта указано "ЗаписьИсторииДанных.ОбновлятьИсториюСразуПослеЗаписи = Ложь", тогда данные попадают в таблицу [_DataHistoryQueue0]. По большому счету это промежуточный буфер.

На данном этапе можно просто выполнить "ИсторияДанных.ОбновитьИсторию()", тогда данные о последней версии перелетят в одну из таблиц [_DataHistoryLatestVersions], [_DataHistoryLatestVersions1], [_DataHistoryLatestVersions2]. А разносная версия улетит в [_DataHistoryVersions].

[_ChangeType] поле с типом изменения из таблицы [_DataHistoryVersions]:

[_ChangeType] = 0 [Добавление]

[_ChangeType] = 1 [Изменение]

[_ChangeType] = 2 [Удаление]

Форма стандартного отбора работает с таблицей [_DataHistoryVersions] при помощи метода:

ВыбратьВерсии(<Отбор>, <Колонки>, <Порядок>, <МаксимальноеКоличество>)

Если включена галка «Выполнить обработку после записи версии данных», тогда при помощи "ИсторияДанных.ОбновитьИсторию(Истина)" можно сделать чтобы данные перелетели в таблицу [_DataHistoryAfterWriteQueue]. Это буфер пост обработки. Если же нужно чтобы после выполнения пост обработчика данные удалились из таблицы [_DataHistoryAfterWriteQueue], тогда можно выполнить ИсторияДанных.ОбновитьИсторию(Истина, Истина). Нужно учесть, что если второй параметр имеет значение Истина, то после выполнения обновления истории и обработки после записи версий истории данных выполняется удаление из обработки после записи версий, дата создания которых меньше текущей на 20 дней.

Передать в постобработку можно также методом:

ВыполнитьОбработкуПослеЗаписиВерсий(<Данные>)

Почистить данные из таблицы [_DataHistoryAfterWriteQueue] можно:

УдалитьИзОбработкиПослеЗаписиВерсий(<ВключитьМетаданные>, <ИсключитьМетаданные>, <Дата>)

4 для таблиц с ExtX1 справедливо все вышеперечисленное.

Схема работы ИД:

Выводы

История данных имеет свои плюсы и минусы, давайте кратко вспомним их:

+- Все муссируют, что ИД «весит меньше». Это скорее миф. На самом деле если у вас данные и структура метаданных не меняются с регулярной постоянностью, тогда ИД будет весить больше.

+ ИД работает из коробки. Это несомненно огромный плюс.

+- Последние значимые изменения по ИД были в платформе 8.3.15, только с этой версии можно полноценно использовать ИД. С другой стороны, все современные конфигурации используют версию платформы выше 8.3.15, а следовательно, только у единиц версия ниже и ИД будет недоступна.

+ ИД может хранить версии не только ссылочных объектов, может хранить версии по регистрам сведений.

+ ИД может настраиваться, не заходя в конфигуратор.

+ ИД может хранить версии удаленных объектов.

+ ИД более гибкая и позволяет восстанавливать версии по тем объектам, чья структура менялась.

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

Лично я не вижу смысла продолжать использовать механизм ВО из БСП, для меня выбор в пользу ИД очевиден, но это сугубо мое мнение. Если вы знаете причины, по которым ИД хуже ВО, прошу, напишите в комментариях.

На этом статью заканчиваю. Желаю всем интересных проектов, надеюсь, статья была вам полезна.

Полезные статьи по этой теме:

Обработка для программной настройки состава "Истории данных"

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

Переход с версионирования объектов БСП на историю данных платформы

История данных. Изменения в платформе 8.3.24

Планы обмена VS История данных