РУБРИКА «ЧёПоСтандартам»
Удаление устаревших объектов метаданных из конфигурации
На практике мне встречались случаи, когда программисты бездумно берут и безвозвратно удаляют реквизиты/документы (объекты метаданных) и т.п. с логикой что-то типа "устарели". Но это может привести к следующим проблемам:
🔸длительной реструктуризации, удаление дольше чем добавление;
🔸поломке обмена, если этот объект использовался (например в КД2);
🔸ошибке при попытке обновления, например, "записи регистра стали неуникальными";
🔸и т.д. и т.п.
Но есть стандарт, который регулирует и этот процесс:
#std534
1. Если при изменении структуры метаданных конфигурации планируется удалить объект метаданных (реквизит, измерение, ресурс и пр.), связанный с записями информационной базы, то необходимо принять решение об удалении или переносе данных этого объекта в новые структуры. При переносе данных в другие объекты рекомендуется придерживаться следующих правил.
1.1. Не удалять из конфигурации устаревшие объекты метаданных и реквизиты безвозвратно, а пометить их как устаревшие, добавив к их именам префикс "Удалить" (англ. "Obsolete"). Например: реквизит "ОсновнойДоговор" (англ. "MainContract") должен быть переименован в "УдалитьОсновнойДоговор" (англ. "ObsoleteMainContract").
В синоним устаревшего объекта (реквизита) рекомендуется добавлять префикс "(не используется)" (англ. "(not used)"), например: "(не используется) Основной договор" (англ. "(not used) Main contract"). Если же устарел стандартный реквизит, то префикс "(не используется)" также добавляется в его синоним.
1.2. После изменения структуры метаданных следует обеспечить перенос данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации.
И вот несколько условий, при которых все-таки можно удалять метаданные:
#std534
3. Безвозвратно удалять устаревшие объекты метаданных и реквизиты, помеченные префиксом "Удалить" (англ. "Obsolete"), следует при выпуске очередных версий конфигурации в том случае, если соблюдается одно из условий:
Переход со "старой" версии конфигурации на новые версии всегда выполняется пользователями последовательно, "через" версию с реализованным переносом данных из "устаревших" объектов метаданных и реквизитов. Например: если в конфигурации версии 1.1 реквизит "ОсновнойДоговор" был помечен как устаревший, то переход с версии 1.0 на версию 2.0 всегда выполняется только последовательно: сначала на версию 1.1 (в которой происходит обработка устаревших данных), а затем на 2.0 (в которой устаревшие данные могут быть удалены безвозвратно). Непосредственный переход с версии 1.0 на 2.0 технически невозможен (запрещен).
Вероятность того, что "старой" версией конфигурации еще пользуются, стала нулевой или пренебрежимо малой.
Как по мне, это достаточно важный стандарт, и либо я всегда прослушивал (да и было это давно), либо про это никогда не говорилось ни на каких курсах, если вы слышали про правильное удаление объектов метаданных на курсах, напишите в комментариях💬 p.s.
Можно даже с указанием курса)
P.S. Полное описание стандарта по ссылке в начале поста
#ЧёПоСтандартам #std534
Удаление устаревших объектов метаданных из конфигурации
На практике мне встречались случаи, когда программисты бездумно берут и безвозвратно удаляют реквизиты/документы (объекты метаданных) и т.п. с логикой что-то типа "устарели". Но это может привести к следующим проблемам:
🔸длительной реструктуризации, удаление дольше чем добавление;
🔸поломке обмена, если этот объект использовался (например в КД2);
🔸ошибке при попытке обновления, например, "записи регистра стали неуникальными";
🔸и т.д. и т.п.
Но есть стандарт, который регулирует и этот процесс:
#std534
1. Если при изменении структуры метаданных конфигурации планируется удалить объект метаданных (реквизит, измерение, ресурс и пр.), связанный с записями информационной базы, то необходимо принять решение об удалении или переносе данных этого объекта в новые структуры. При переносе данных в другие объекты рекомендуется придерживаться следующих правил.
1.1. Не удалять из конфигурации устаревшие объекты метаданных и реквизиты безвозвратно, а пометить их как устаревшие, добавив к их именам префикс "Удалить" (англ. "Obsolete"). Например: реквизит "ОсновнойДоговор" (англ. "MainContract") должен быть переименован в "УдалитьОсновнойДоговор" (англ. "ObsoleteMainContract").
В синоним устаревшего объекта (реквизита) рекомендуется добавлять префикс "(не используется)" (англ. "(not used)"), например: "(не используется) Основной договор" (англ. "(not used) Main contract"). Если же устарел стандартный реквизит, то префикс "(не используется)" также добавляется в его синоним.
1.2. После изменения структуры метаданных следует обеспечить перенос данных из устаревших объектов и реквизитов в новую структуру метаданных конфигурации.
И вот несколько условий, при которых все-таки можно удалять метаданные:
#std534
3. Безвозвратно удалять устаревшие объекты метаданных и реквизиты, помеченные префиксом "Удалить" (англ. "Obsolete"), следует при выпуске очередных версий конфигурации в том случае, если соблюдается одно из условий:
Переход со "старой" версии конфигурации на новые версии всегда выполняется пользователями последовательно, "через" версию с реализованным переносом данных из "устаревших" объектов метаданных и реквизитов. Например: если в конфигурации версии 1.1 реквизит "ОсновнойДоговор" был помечен как устаревший, то переход с версии 1.0 на версию 2.0 всегда выполняется только последовательно: сначала на версию 1.1 (в которой происходит обработка устаревших данных), а затем на 2.0 (в которой устаревшие данные могут быть удалены безвозвратно). Непосредственный переход с версии 1.0 на 2.0 технически невозможен (запрещен).
Вероятность того, что "старой" версией конфигурации еще пользуются, стала нулевой или пренебрежимо малой.
Как по мне, это достаточно важный стандарт, и либо я всегда прослушивал (да и было это давно), либо про это никогда не говорилось ни на каких курсах, если вы слышали про правильное удаление объектов метаданных на курсах, напишите в комментариях💬 p.s.
Можно даже с указанием курса)
P.S. Полное описание стандарта по ссылке в начале поста
#ЧёПоСтандартам #std534