Механизм миграции вызывается не только когда разработчик приложения явно поменял тип у реквизита,
но и при изменении структуры системных таблиц "под капотом" элемента. Примеры работы алгоритма миграции данных:
1. Если в составе типа есть "время", то алгоритм попытается сделать всё чтобы в новых данных не обрезалось время,
например, при удалении "ДатаВремя" из типа "ДатаВремя|Дата|Момент", "Элемент" преобразует сначала данные к типу "Момент", где время есть, и лишь в последнюю очередь к типу "Дата"
2. Если удаленный тип не относится к типам работы с датой, тогда на его месте будет установлено значение по умолчанию по оставшемуся типу (например, 0 у "Число", или "" у Строка)
3. При удалении типа из состава элементов реквизита-массива (например
Массив<Строка|Число> → Массив<Строка>) при миграции проверяется, что в данных (таблице реквизита) нет записей с указанным типом элементов. Если записи с удаленным типом элементов есть — выдается ошибка и миграция данных не выполняется.
4. При изменении периодичности регистра с "Секунда" на "День", "Месяц", "Квартал" или "Год" меняется тип значения стандартного поля Период с "ДатаВремя" на "Дата" и наоборот.
5. Во время миграции данных для удаленного типа проверяется присутствие этого типа в таблицах как значения некоторого поля с типом "Тип".
Если значения найдены — выдается ошибка и миграция не выполняется.
Когда разработчик осознанно меняет структуру данных проекта и не уверен в алгоритме миграции, рекомендую зайти лишний раз на страницу алгоритма в
документации, здесь подробно перечислены все существующие правила технологии
#база #миграцияданных