Удаление устаревших объектов метаданных из конфигурации

#std534

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

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

1.1. Не удалять из конфигурации устаревшие объекты метаданных и реквизиты безвозвратно, а пометить их как устаревшие, добавив к их именам префикс "Удалить" (англ. "Obsolete"). Например: реквизит "ОсновнойДоговор" (англ. "MainContract")  должен быть переименован в "УдалитьОсновнойДоговор" (англ. "ObsoleteMainContract").

В синоним устаревшего объекта (реквизита) рекомендуется добавлять префикс "(не используется)" (англ. "(not used)"), например: "(не используется) Основной договор" (англ. "(not used) Main contract"). Если же устарел стандартный реквизит, то префикс "(не используется)" также добавляется в его синоним.

1.2. После изменения структуры метаданных следует обеспечить перенос данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации.

1.3. Если удаляемый объект метаданных является документом – регистратором движений, а соответствующие регистры с движениями остаются в составе конфигурации, то необходимо обратить внимание на необходимость сохранения движений. Для сохранения движений документов – устаревших объектов метаданных, рекомендуется:

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

Исключение составляет только сам код переноса данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации (см. п.1.2).

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

1.6. Также рекомендуется выполнить очистку устаревших данных с тем, чтобы они не влияли на размер базы и не потребляли ресурсы (при резервном копировании, реструктуризации и других операциях).

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

2. Необходимость в переносе данных также может возникнуть при пересмотре структуры измерений регистров:

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

При этом создать новый регистр не требуется, если в регистр добавляется новое измерение или у измерения составного типа расширяется состав типов.

3. Безвозвратно удалять устаревшие объекты метаданных и реквизиты, помеченные префиксом "Удалить" (англ. "Obsolete"), следует при выпуске очередных версий конфигурации в том случае, если соблюдается одно из условий:

  1. Переход со "старой" версии конфигурации на новые версии всегда выполняется пользователями последовательно, "через" версию с реализованным переносом данных из "устаревших" объектов метаданных и реквизитов. Например: если в конфигурации версии 1.1 реквизит "ОсновнойДоговор" был помечен как устаревший, то переход с версии 1.0 на версию 2.0 всегда выполняется только последовательно: сначала на версию 1.1 (в которой происходит обработка устаревших данных), а затем на 2.0 (в которой устаревшие данные могут быть удалены безвозвратно). Непосредственный переход с версии 1.0 на 2.0 технически невозможен (запрещен).
  2. Вероятность того, что "старой" версией конфигурации еще пользуются, стала нулевой или пренебрежимо малой.

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