Object import strategies
This topic describes the import strategies that define how to match objects and resolve conflicts between objects during replication import. The ID-based and the Name and ID-based import strategies are available.
In this topic:
ID-based strategy
The ID-based strategy is the legacy replication import strategy. It matches two objects based on their IDs and considers them to be identical if the IDs match. The strategy allows mainly source–target replication scenarios.
Name and ID-based strategy
The Name and ID-based strategy matches two objects based on ID and name. This is the default import strategy.
The strategy uses the following matching sequence:
- The system matches objects based on their IDs (the ID-based strategy).
- If that fails, the system finds two matching objects with different IDs but identical names. The two objects are treated as a match.
- If there are no matching objects, the system creates a new object on the server.
The Name and ID-based strategy works as follows:
- When a versioned entity is imported, the server remembers its path and version number and does not import it again.
-
When a server imports an object matched by name, all versions that were not previously imported are imported as the latest version, maintaining the order from the replication file.
Example: In this example, a server has app1 with id1 and one version of the properties. The server imports app1 with id2 with two versions of the properties.
Result: The properties for app1 look like this:
- app1, id1, version 1 properties (version 1 on the server)
- app1, id2, version 1 properties (version 2 on the server)
- app1, id2, version 2 properties (version 3 on the server; the latest version)
The following table explains how name conflicts are resolved.
Server (target) | Replication (source) | Result | Description | |||
---|---|---|---|---|---|---|
ID | Name | ID | Name | ID | Name | |
id1
|
name1
|
id1
|
name2
|
id1
|
name2
|
No conflict. |
id1
|
name1
|
id2
|
name1
|
id1
|
name1
|
Two entities with different IDs have the same name. The conflict is resolved by replacing the ID of the replication (source) entity with the ID of the server (target) entity. |
id1
|
name1
|
id1
|
name2
|
Conflict | No resolution, and there is a conflict. | |
id2
|
name2
|
id2
|
name1
|
Resolve long name conflicts
You can import replication files with entities names that are longer than permitted.
Long names are shortened to the first name that is legal and not occupied. A shortened name looks like this:
<first part of the name> < text> <length limit exceeds ~31>
If the system identifies a conflict with an existing name, the index is automatically incremented to resolve conflicts.
See also: