Managing obsolete metadata objects

Scope: managed applications, mobile applications, and ordinary applications.

1. When you modify the structure of metadata objects and need to remove an object that has records in the infobase, these records must be either deleted or migrated to the new structure. If you choose to migrate the records, stick to the following recommendations.

1.1. Do not delete obsolete metadata objects and attributes. Instead, add prefix Obsolete to their names. For example, effective attribute name: MainContract. Obsolete attribute name: ObsoleteMainContract.

Also, it is recommended that you add prefix (not used) to the synonyms of obsolete objects and attributes. For example, (not used) Main contract.

1.2. Once you change a metadata structure, migrate the data from the obsolete objects and attributes to the new metadata structure.

1.3. If the deleted document is a recorder, and its registers are kept as a part of the configuration, consider keeping the records. To save the register records of an obsolete document, take the following steps:

Disable creating new register records when the document is posted.
Disable clearing deletion marks for the document.
In all registers that contain this document as a recorder, replace the document with a substitute document. There are general and ad-hoc recorders. For example, Data migration and Operation.
Mark the document for deletion.

1.4. Review the configuration and replace references to the obsolete objects and attributes with references to the new objects. Exclude the obsolete metadata objects from all roles (except for roles FullAccess and SystemAdministrator), event subscriptions, etc. Delete their code, forms, templates, commands, and other items that have become redundant.

The only exception is the code used for data migration from the obsolete objects and attributes to the new metadata structure (see item 1.2).

1.5. When sorting obsolete metadata objects and attributes in the metadata tree, stick to the general configuration requirements.

1.6. It is recommended that you purge the obsolete data from the database to clear the space and improve the performance during backups, restructuring, and other operations.

In case the data migration algorithms are complicated and are likely to cause errors, schedule the purge after one or a few releases. By that, you will have the time to release a bugfix in case the migration has failed.

2. Another reason for data migration might occur after reviewing the structure of register dimensions:

When a dimension becomes obsolete. A dimension can be considered obsolete when it is removed, its type is changed or, for composite type dimensions, the list of types narrows down.
When you need to clear the Main filter flag for a register dimension included in exchange plans, which is equivalent to deleting a field from a database table.

In this case, deleting a field from a database table would result in the "Register records are no longer unique" restructuring error. To avoid this, create a new register with the correct structure, mark the old one as obsolete, and migrate the records to the new register.

However, if a new dimension is added to a register or the list of dimension types expands, a new register is not required.

3. Before releasing a new version, permanently delete the Obsolete metadata objects and attributes if any of the following conditions is met:

First, users install all intermediate upgrades from the earlier version to the later version. Only then, they can update the configuration to the latest version. For example, if in version 1.1 attribute MainContract is marked as obsolete, to migrate from version 1.0 to version 2.0 the intermediate update is required. First, you need to update to version 1.1, where the obsolete data is processed. Only then, you can update to version 2.0, where the obsolete data is purged. The direct update from version 1.0 to 2.0 is forbidden.
The old version is very unlikely to have any active users.

Note that you might need to release an intermediate update first to purge the data. See 1.6. Otherwise, if the registers have dimensions that refer to obsolete data, the restructuring might fail.

<< Prev Next >>