При сопровождении, обновлении или доработке типовых конфигураций на платформе 1С:Предприятие 8 разработчики часто сталкиваются с объектами метаданных, имена которых начинаются со слова «Удалить» (например, УдалитьОсновнойДоговор, УдалитьСтатус) или синонимами, содержащими пометку «(не используется)». Давайте подробно разберем, почему появляется такой префикс, как устроен жизненный цикл этих объектов, зачем они нужны платформе и как правильно поступать программисту, если его доработки зависят от подобных реквизитов.
Появление таких объектов — это не хаотичное решение отдельных программистов, а строго регламентированная часть «Системы стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8» (в частности, Стандарта № std534). Когда в процессе эволюции типового решения меняется его архитектура (например, учет переносится из реквизитов шапки документа в табличные части или в отдельные регистры сведений), старые реквизиты нельзя просто так взять и физически удалить из конфигурации.
Если разработчик вендора сразу удалит реквизит из файла конфигурации (.cf), то при первом же обновлении у пользователей безвозвратно пропадут накопленные за годы работы данные. Чтобы избежать потери информации, применяется механизм постепенного вывода объектов из эксплуатации. Первым шагом в этом процессе является переименование объекта.
Согласно стандартам разработки 1С:
Obsolete). Например, реквизит ВидДоговора превращается в УдалитьВидДоговора.(not used)). Например: «(не используется) Вид договора». Это визуально подсказывает пользователям и администраторам в интерфейсе, что поле устарело.Процесс полного вывода реквизита или объекта из базы данных — это многоэтапная процедура, которая может растянуться на несколько месяцев или даже лет (в зависимости от частоты выхода обновлений конфигурации). Давайте проанализируем этот жизненный цикл по шагам:
Шаг 1. Переименование и разработка обработчиков перехода. В релизе, где изменяется логика учета, реквизит переименовывается в УдалитьИмяРеквизита. Одновременно с этим создается новая структура для хранения данных. В модулях обновления информационной базы (чаще всего на базе Библиотеки Стандартных Подсистем — БСП) пишется специальный программный обработчик. При запуске обновленной базы этот обработчик автоматически считывает данные из старого реквизита Удалить..., конвертирует их при необходимости и записывает в новую структуру.
Шаг 2. Период сосуществования. В течение нескольких последующих релизов устаревший реквизит продолжает физически существовать в таблицах базы данных СУБД. Это необходимо для того, чтобы пользователи, которые пропускают промежуточные обновления и обновляются с очень старых версий, не потеряли данные. При переходе обработчик обновления все равно сможет прочитать информацию из сохраненного поля.
Шаг 3. Окончательное удаление. Когда вендор понимает, что критическая масса пользователей уже обновилась на релизы с новыми структурами данных, старый реквизит полностью удаляется из метаданных конфигурации. Обычно это происходит через несколько крупных редакций. Прямой переход со слишком старой версии на самую новую блокируется на уровне требований к обновлению: система попросит сначала установить промежуточный релиз, чтобы корректно отработали все конвертации данных.
Рассмотрим, как технически выглядит обработка таких реквизитов в коде обновления. При обновлении конфигурации через БСП регистрируются специальные процедуры. Примерный концепт обработчика обновления, который переносит данные из устаревшего реквизита шапки документа в новый регистр сведений, выглядит следующим образом:
Процедура ПеренестиДанныеИзУстаревшегоРеквизита(Параметры) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Ссылка КАК ДокументСсылка,
| УдалитьСтатусРешения КАК СтарыйСтатус
|ИЗ
| Документ.ЗаявкаНаОплату КАК ЗаявкаНаОплату
|ГДЕ
| УдалитьСтатусРешения <> ЗНАЧЕНИЕ(Перечисление.СтатусыЗаявок.ПустаяСсылка)";
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// Запись данных в новую структуру (например, в регистр сведений)
МенеджерЗаписи = РегистрыСведений.ИсторияСтатусовЗаявок.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Документ = Выборка.ДокументСсылка;
МенеджерЗаписи.Статус = Выборка.СтарыйСтатус;
МенеджерЗаписи.Период = Выборка.ДокументСсылка.Дата;
Попытка
МенеджерЗаписи.Записать(Истина);
Исключение
ЗаписьЖурналаРегистрации("Обновление информационной базы",
УровеньЖурналаРегистрации.Ошибка,
Метаданные.РегистрыСведений.ИсторияСтатусовЗаявок,
Выборка.ДокументСсылка,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
КонецЦикла;
КонецПроцедуры
Этот код запускается один раз при обновлении на новый релиз. Как только все данные успешно мигрировали, старое поле УдалитьСтатусРешения становится не нужным для работы текущей логики программы.
Как только реквизит переводится в статус «Удалить...», разработчики типового решения проводят глобальную ревизию конфигурации:
ПолныеПрава и АдминистраторСистемы (это необходимо, чтобы подсистема обновления БСП могла беспрепятственно считать данные под административной учетной записью).Выясним причину, почему разработчики 1С со временем не просто удаляют метаданные, но и принудительно очищают их содержимое на промежуточных этапах. В базах данных с миллионами записей устаревшие колонки таблиц СУБД могут занимать гигабайты дискового пространства.
Если оставить эти неиспользуемые данные, то:
.dt или бэкапов SQL).Поэтому в правилах разработки заложено требование: после успешного переноса данных в новые структуры запустить фоновую очистку старых реквизитов (запись пустых значений). Это высвобождает место на диске и подготавливает базу к беспроблемному физическому удалению поля в будущем.
Рассмотрим ситуацию: вы обновили конфигурацию и обнаружили, что реквизит, на который опирался ваш нетиповой отчет или внешняя обработка, теперь называется УдалитьОбъем или УдалитьДоговор. Действовать в такой ситуации нужно незамедлительно, не дожидаясь, пока этот объект будет удален полностью.
Разберем по шагам алгоритм ваших действий:
Шаг 1. Выясните новую архитектуру хранения данных. Проанализируйте, куда теперь записываются эти данные в типовом решении. Сделать это можно следующими способами:
ОбновлениеИнформационнойБазы).ReadMe.txt или ссылку на описание изменений на сайте ИТС).Шаг 2. Перепишите ваши доработки под новые правила. Настройте ваши запросы, отчеты и печатные формы так, чтобы они брали информацию из нового источника. Например, если раньше вы получали объем номенклатуры напрямую из реквизита справочника, а теперь данные переехали в регистр сведений ПараметрыНоменклатуры, скорректируйте текст запроса.
Шаг 3. Создайте собственный реквизит (если аналогов нет). Бывают случаи, когда фирма 1С полностью отказывается от поддержки определенной бизнес-логики и удаляет реквизит без замены на другой. Если вашему бизнесу эти данные жизненно необходимы, выполните следующие действия:
ит_Объем), чтобы избежать конфликтов при последующих обновлениях.УдалитьОбъем в ваше новое поле ит_Объем, пока старый реквизит еще физически присутствует в базе данных.Пример простой обработки для переноса данных в ваш собственный реквизит перед окончательным удалением типового:
Процедура ПеренестиДанныеВЛокальныйРеквизит() Экспорт
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
// Проверяем, заполнено ли старое удаляемое поле и не заполнено ли уже новое
Если ЗначениеЗаполнено(Выборка.УдалитьОбъем) И Не ЗначениеЗаполнено(Выборка.ит_Объем) Тогда
ОбъектНоменклатуры = Выборка.ПолучитьОбъект();
ОбъектНоменклатуры.ит_Объем = Выборка.УдалитьОбъем;
Попытка
// Отключаем проверки при записи, чтобы ускорить процесс и избежать конфликтов логики
ОбъектНоменклатуры.ОбменДанными.Загрузка = Истина;
ОбъектНоменклатуры.Записать();
Исключение
ЗаписьЖурналаРегистрации("ПереносДанных",
УровеньЖурналаРегистрации.Предупреждение,
Метаданные.Справочники.Номенклатура,
Выборка.Ссылка,
ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Использование свойства ОбменДанными.Загрузка = Истина позволяет обойти платформенные проверки и обработчики событий при записи объекта, что критически важно при массовом обновлении исторических данных в работающей базе.
Таким образом, наличие префикса «Удалить» — это предупреждающий сигнал для технического специалиста. Он сообщает о том, что архитектура конфигурации изменилась, и дает время на адаптацию ваших доработок под новые стандарты до того, как устаревший объект будет окончательно стерт из базы данных.