Scope: managed applications, mobile applications, and ordinary applications.
1. If upon editing the configuration metadata structure, you plan to delete a metadata object (attribute, dimension, resource, and other) related to infobase records, delete or transfer this object data to new structures. When you transfer data to other objects, follow these rules.
1.1. Avoid permanently deleting obsolete metadata objects and attributes. Mark them as obsolete and add the Obsolete prefix to their names.$$$ For example: rename the MainContract attribute to ObsoleteMainContract $$$
We recommend that you add (not used) prefix to synonyms of obsolete objects (attributes), for example: (not used) Main contract . If a standard attribute becomes obsolete, add (not used) prefix to its synonym as well.
1.3. If a metadata object being deleted is a recorder document of register records, and respective registers with register records remain in the configuration, make sure the records are saved. To save document register records, which are obsolete metadata objects, we recommend that you:
- Restrict generation of register records when posting documents of this kind.
- Restrict clearing a deletion mark for documents of this kind.
- Replace a recorder in all existing register records of documents of this kind with one or several recorder documents: existing universal or specially developed ones. Examples: Data transfer, Operation.
- Mark all documents of this kind for deletion.
In case of complex or error-intensive data transfer algorithms, clear such data in one or several releases. An unscheduled release can be issued to eliminate incorrect execution of transfer algorithms.
2. You might also need to transfer data when revising a register dimension structure. Create a register with a proper structure, mark the previous one as obsolete and transfer records from the previous register to the new one if the information register dimension becomes irrelevant. Its type is either deleted or modified or the number of types is reduced for the composite type dimension.
It is not required to create a new register if a new dimension is added to the register or the number of types is expanded for composite type dimensions.
- Migration from obsolete configuration versions to new versions is always made by users consistently using a version with implemented data transfer from obsolete metadata objects and attributes. For example: if in configuration 1.1 the MainContract attribute is marked as an obsolete attribute, migration from version 1.0 to version 2.0 is always made consistently, first to version 1.1 (in which obsolete data is processed) and then to version 2.0 (in which obsolete data can be deleted permanently). It is restricted to migrate directly from version 1.0 to version 2.0.
- The obsolete configuration version is no longer in use.
An intermediate version release might be required to clear obsolete data (see cl. 1.6). Otherwise, restructuring of registers whose dimensions still refer to obsolete data might cause errors.