Scope: managed applications, mobile applications, and ordinary applications.
Otherwise, when comparing or merging with a new vendor configuration, for example, in event subscriptions that refer to a common module, a link by name will be established with a new common module (not a renamed one) without required procedures.
2. In some cases, upon metadata structure change, there is a need to delete a metadata object and create a new one with the same name. For example, when narrowing dimensions in a register. In such cases, rename an obsolete metadata object by adding the Delete prefix to its name.
Otherwise, if you delete a metadata object and create a new one with the same name, an error might occur upon updating a supported configuration. If a supported configuration have some changes to an obsolete object but is still supported (for example, to override the object behavior or fix errors), this object will not be deleted when merging configurations and any attempt to update a database configuration will fail due to two metadata objects (the old object and new object) with the same name.
3.1. If Standard Subsystems Library (SSL) is not used in a configuration, we recommend that you create string attributes (String, 255) to store full names of metadata objects. For example, the InputOnBasisParameterTypeFullName attribute in the MessagesTemplates catalog, the ObjectType dimension in the ObjectsPrintingSettings information register, and other.
If metadata objects are renamed or deleted in the configuration, all names stored in the base must also be replaced or deleted upon infobase update. Otherwise, references to metadata object names will become inconsistent. It will cause various errors in configuration subsystems that are based on the metadata object names.
The exceptions are roles and subsystems, for which renames are not tracked automatically. It is required to explicitly describe renames for them. For more information, see SSL documentation.
Otherwise, if you do not specify renaming of roles and subsystems, their references in the MetadataObjectsIDs catalog will become inconsistent (an old catalog item will be marked for deletion and a new one will be created instead), which will lead to various errors in the configuration subsystems that are based on this catalog data. For example:
3.3. The MetadataObjectsIDs catalog cannot store references to metadata objects of other configurations (for example, in mechanism that provide integration with other systems). For this purpose, use attributes of String type and develop special mechanisms to keep their values up-to-date.
3.4. When two or more parallel branches of development take place, for example, versions 2.0 and 3.0 are released or corrective releases are issued together with new functional releases, consider the following: Renaming followed by creation of a new metadata object with the same full name is prohibited in the current and earlier configuration versions, as well as double renaming. Perform such renames only in the latest version, that is, 3.0.
Otherwise, this rename will be considered twice upon migration from an earlier version to an older version, which will lead to inconsistent references to metadata objects.
If references to the MetadataObjectsIDs catalog of Standard Subsystems Library are used, this prohibition applies to roles and subsystems only.