Available with Standard or Advanced license.
During replica creation, rows and features are added to a replica based on the filters defined in the application. Once this is completed, relationship classes are processed to include additional related objects.
Relationship class processing involves evaluating each dataset that participates in at least one relationship class. When a dataset is evaluated, all rows that have already been replicated are collected and used to query for related rows in the related datasets. Any related rows returned from the queries are added to the replica. Each dataset is visited once during this process.
Each relationship class is processed in only one direction. By default, the direction is forward, but this can also be changed to backward at creation time. A forward direction means that the origin class is evaluated to add related rows from the destination class to the replica. A backward direction means that the destination class is evaluated to add related rows from the origin class to the replica. It is also possible to turn off relationship class processing for a specific relationship class during replica creation.
Since each dataset is evaluated once, and each relationship class is processed in, at most, one direction, the order in which the datasets are evaluated is important. The system has logic to process the datasets in the order for which the most related objects will be added. You can affect the order in which datasets are processed by changing the direction or turning off processing for specific relationship classes.
The following examples will illustrate the replication behavior with respect to related objects. The data model used in these examples is a simple origin–destination relationship between properties, buildings, and their related annotation.
Example one
This example shows the replica area covering eight parcels and six buildings. When the replica is created, two additional buildings are added, since they're related to the parcels. Relationship class processing also adds annotation for the building and parcels to the replica.
Example two
This example shows replicating relationships through forward processing. By selecting the two buildings in the parent replica for replication and using the default forward processing direction for related records, the annotation related to those buildings also gets replicated to the child.
The next diagram shows a case where you choose those same two buildings but decide to use a backwards processing direction for the prop_build relationship class. Here, in addition to the related building annotation, the parcels related to those buildings, as well as the parcels' annotation, are included.
Example three
In the previous examples, a replica was made using the default behavior of including related objects. It is possible to override this behavior either at the global or local level to customize replication. At the global level, the replication process may be configured to not include any related objects associated with features identified for replication.
In this example, the buildings and properties are selected in the replica area, but since the option to exclude related records was chosen, the annotation associated with the buildings and parcels is not replicated.
Example four
In this example, although the replica area includes four properties (17691, 17692, 17698, 17697) that have related buildings, all buildings have been explicitly excluded from replication. Since the global default behavior to always include related objects is still in effect for the other feature classes, the property annotation will again be included in the replica.
Example five
This example shows what happens in the case of a circular relationship. During the replica creation process, the system applies some logic to break the circle to prevent it from processing in an endless loop. However, this logic makes it such that the order in which relationships are processed can't be predicted.
To get a predictable result in the case of circular relationships, you can choose to not process one of the relationships or choose backward processing for one of the relationship classes. For example, the diagram below shows the case where R3 is set to process backwards. Now the order of processing is predictably T1 - T2 - T3. Here, T3 will have related records added from T1 and T2, but no records from T3 will be added to T1 or T2.
Relationship classes where an ObjectID field is the primary key field
Replicating with relationship classes where an ObjectID field is used as a primary key field requires additional processing during synchronization, which can affect performance. It can also result in unexpected behavior in some cases. The following describes these in more detail. After reviewing this section, you may decide to modify your relationship classes to use primary key fields other than the ObjectID field. Good alternatives include these:
- Relationship classes with a primary key field of type GlobalID and a foreign key field of type GUID
- Your own primary key field, which is unique across all databases
Additional processing during synchronization when the ObjectID field is the primary key field
The ObjectID values in a feature class or table are not unique across geodatabases. A new row in one replica geodatabase may be allocated the same ObjectID as a completely different row in the other replica geodatabase. The synchronization process must account for these differences when transferring relationships across replica geodatabases when the primary key in the relationship is an ObjectID column. To accomplish this, the synchronization process detects relationship classes that use the ObjectID column. If any such classes are present, the synchronization process transmits additional information that is then used to perform additional processing. The processing involves adjusting foreign key values to target the appropriate ObjectID value in the target geodatabase for each edited relationship. In cases where a large number of relationships are edited, this additional processing may have a noticeable effect on synchronization performance.
Unexpected behavior when the ObjectID field is the primary key field
The following describes cases where you may see unexpected behavior:
Edits where the origin row does not exist in the target replica geodatabase—As described above, the synchronization process performs additional processing in order to maintain relationships when an ObjectID field is the primary key field in a relationship class. A relationship is not maintained, however, in cases where the edit involves referencing an origin row that does not exist in the relative replica geodatabase. For an insert, this results in the foreign key being set to null in the destination row. For an update, the foreign key value is left as it existed prior to the synchronization in the destination row. Note that this behavior will not happen with checkout replicas.
The diagram above shows a case where a simple relationship class exists between parcels and buildings where the ObjectID field of the parcels feature class is the origin primary key. In this example, a replica is created for only the parcels and buildings within a spatial extent. After the replica is created, however, a digitizing error is detected where a building is found to have been digitized in the wrong parcel. This is corrected in the parent replica geodatabase by moving the building and editing the relationship such that it is related to the correct parcel. The replica is then synchronized to apply the changes to the child replica. In this case the building is moved, but it is still related to the incorrect parcel in the child replica. The relationship was not changed in the child replica because the correct origin row (parcel with ObjectID 102 in the parent) does not exist in the child replica geodatabases. In these cases, relationships are not altered.
Dangling foreign keys—
When creating a replica, rows are copied from the source geodatabase to the target geodatabase based on how the replica is defined. When defining the replica, you can choose to include rows from the destination table without the related rows in the origin table. The foreign key values in the destination table for these unrelated rows are the same as they are in the source geodatabase. These are dangling foreign keys since the origin row they reference does not exist in the target geodatabase.
The diagram above describes an example of where unexpected behavior can result from having dangling foreign keys. Here, the parent replica geodatabase has a simple relationship class between parcels and buildings. The parcel feature class is the origin and uses the ObjectID field as the primary key. A replica is created to include all buildings in the city and parcels for one city block. The replica creation process copies the appropriate parcels and buildings from the parent replica geodatabase to the child replica geodatabase. In the child replica, buildings related to parcels outside the city block have dangling foreign keys since these parcels are not part of the replica. For example, the building with a foreign key of 100 has a dangling foreign key since the parcel with ObjectID 100 does not exist in the child. If a new parcel is created in the child replica and is assigned an ObjectID of 100, it will be unintentionally related to the building.