Object mapping
Mapping rules
When merging configurations, 1C:Enterprise creates the mapping of metadata objects based on their Name properties and internal object IDs. The mapping algorithm to be used depends on which comparison option you have selected. Before we proceed to describe these options, let us discuss how internal object IDs can be changed.
Internal IDs are never changed within a single configuration. They are not changed when you export configurations to .cf or .dt files (including .cf distribution files and .cfu update files). They are not changed in the process of shared development (when you move objects between the configuration and the repository). However, they are always changed when you copy objects, and this includes copying objects in the process of merging.
For example, you create a new configuration and then, on the Configuration menu, click Compare and merge with configuration from file. 1C:Enterprise detects that the current configuration is empty and prompts you to load the entire configuration from a file, as if you used the Load configuration from file command. If you agree, all object IDs are preserved. If you decline and perform regular merging, all object IDs are changed, although the resulting configuration is logically identical to the original one.
Now let us proceed to object mapping algorithms. Three algorithms are available:
- Comparison of configurations that are not related to each other. The mapping is based on object names. Objects that cannot be mapped by name are mapped by an intermal ID.
- Comparison of configurations related to each other (different versions of a single configuration). For example, comparison of a base configuration with a database configuration or with a repository configuration falls into this category. The mapping is based on object IDs only, object names are ignored.
- Comparison with vendor configuration. The mapping is based on object IDs but the IDs do not have to be identical.
Let us look into the third algorithm in detail, but first let us make some clarifications to the first two algorithms. There are several ways to start configuration comparison. For example, you can use the Configuration - Compare and merge with the configuration from file command, or the Configuration - Database configuration - Compare and merge with database configuration command, or open it from the support options dialog box. In each of these scenarios the platform automatically selects the mapping algorithm.
You also have the universal comparison command Configuration - Compare configurations, which prompts you to select any pair of configurations (for example, a database configuration and some configuration version from the repository). If you select a pair of configurations that are obviously related to each other, the mapping algorithm is selected automatically. Otherwise, the Determine match by object names checkbox, which allows you to select between two algorithms, becomes available.
Note that for the platform to select the algorithm automatically, in addition to selecting a specific pair of configurations, you also have to select them in the right order, the base configuration should go first. You can use this feature if you want to change the algorithm for a certain pair of configurations: just change their order.
Now let us look into the comparison with vendor configuration. If can have one of the two support options: object changes allowed or not allowed. In the latter case the update is performed by loading the entire vendor configuration and the object IDs are not changed, as it is described earlier in this article. In the former case manual corrections are allowed during the merging and new objects acquire new IDs. But is this scenario objects cannot be mapped by name because otherwise objects whose names are changed by customer would lose their links to vendor objects. So the platform uses the following algorithm: for each vendor object, it stores a pair of object IDs (the vendor object ID and the supported configuration object ID), and then generated the mapping using those pairs only. Once created, the pairs are never changed, this ensures the logical integrity of the configuration. If a new object is found in a vendor configuration, a customer can copy the object during the update or they can map it to some custom configuration object, and once they do, this mapping cannot be changed.
Dependence of configuration comparison performance on the object mapping
Comparison of large configurations is a lengthy operation, especially in the update vendor configuration mode, which includes three comparisons: the old vendor configuration, the new vendor configuration, and the customer configuration are compared to each other. Generally, the comparison performance is significantly improved if the following two conditions are met:
- The mapping does not include objects pairs with different IDs.
- Unmapped objects do not include object pairs with identical IDs.
One can easily explain why following these rules optimizes the performance. Vendor configuration versions are always compared quickly because they are created from a single configuration as delivery or update files and the object IDs are preserved. The comparison performance depends on the change history in the vendor configuration versions. After enabling changes in the customer configuration the comparison is still performed quickly because the mapped objects have identical IDs. But once a vendor adds a new object in an update, the object is assigned a new ID after the update and the performance of all subsequent comparisons of the customer configuration with the vendor configuration is significantly reduced.
Note on enabling support
Deployment specialists often ask which is the right way to enable support. They have the following options: either enable support in a vendor configuration installed from a distribution kit, or merge a customer configuration with the distributed vendor configuration and at the same time enable support. There is no big difference between these options. Logically, both ways give the same result. The update performance is initially better in the first scenario, but only until the vendor adds at least one object, which will most likely happen in the next release of the vendor configuration. After that the performance is the same for both scenarios.
Deletion of vendor objects
Let us consider scenarios that involve deleting vendor objects.
Deletion by customer
In order to delete a vendor object, a customer has to disable support for this object and all its subordinate objects. In subsequent updates the object is excluded from merging.
Deletion by vendor
When you merge configurations, you always have the option to delete base configuration objects. By default this option is only available in the "vendor configuration update" mode. In other modes you can enable it by selecting the Allow base configuration object deletion checkbox in the compare and merge configuration dialog box.
By default setting deletion marks to vendor objects is performed according to the following rules. If a customer changed the vendor object (compared to the previous version of the vendor configuration), the deletion mark is not set by default. If the object is identical to the vendor object, the deletion mark is set. Once you click Execute, the platform checks the reference integrity for objects that have deletion marks set both automatically and manually. If unresolvable references to an object that has a deletion mark are found, the list or references is displayed in a new window. Unlike the unresolved references that are found when you deny copying an object from a vendor configuration (or from any other configuration involved in the merging), these references do not allow you to delete the object and continue the merging.
Next page: Specifying support options