ArcGIS Runtime SDK for iOS
100.15
|
Information about a feature table's relationship.
Instances of this class represent information about a relationship that a feature table participates in.
A relationship consists of two and only two tables, each having one of these roles in the relationship:
A table can participate in more than one relationship. It may be an origin table in one relationship and a destination table in another relationship.
The relationship's cardinality describes whether features in a table are related to only one feature in the other table, or whether a feature may be related to multiple features.
In a simple relationship, the features in the participating tables can exist without the other. For example, a transformer and an electric pole may be related but one's existence does not depend on the other. Deleting the origin features will simply disassociate the destination features from the origin features.
In a composite relationship, the destination features cannot exist without the origin features. This means that each destination feature must be linked to a counterpart origin feature. When an origin feature is deleted, the related destination feature is deleted as well. This is called a cascade delete. The related feature is deleted on the client if it exists locally, otherwise it is deleted by the service when the origin feature's deletion is applied or synced to the service. Edits that result in orphan features (A feature in the destination table that’s not related to origin feature) can be checked for constraint violation. For more info on checking constraint violations, and recovering from them, see AGSArcGISFeature::validateRelationshipConstraintsForFeature:completion:
.
Properties | |
AGSRelationshipCardinality | cardinality |
BOOL | composite |
NSString * | keyField |
NSString * | keyFieldInRelationshipTable |
NSString * | name |
NSInteger | relatedTableID |
NSInteger | relationshipInfoID |
NSInteger | relationshipTableID |
AGSRelationshipRole | role |
|
readnonatomicassign |
Cardinality of the relationship (from origin table to destination table). It describes whether features in the origin table are related to only one feature in the other table, or whether a feature may be related to multiple features.
|
readnonatomicassign |
Indicates whether the relationship is composite or simple.
In a simple relationship, the features in the participating tables can exist without the other. For example, a transformer and an electric pole may be related but one's existence does not depend on the other. Deleting an origin feature will simply disassociate its related destination features.
In a composite relationship, the destination features cannot exist without the origin features. This means that each destination feature must be linked to a counterpart origin feature. When an origin feature is deleted, the related destination feature is deleted as well. This is called a cascade delete. The related feature is deleted on the client if it exists locally, otherwise it is deleted by the service when the origin feature's deletion is applied or synced to the service. Edits that result in orphan features (A feature in the destination table that’s not related to origin feature) can be checked for constraint violation. For more info on checking constraint violations, and recovering from them, see AGSArcGISFeature::validateRelationshipConstraintsForFeature:completion:
.
|
readnonatomiccopy |
Name of the key field that links the origin and destination tables of this relationship.
|
readnonatomiccopy |
The key field in the relationship table.
Used in many-to-many and attributed relationships. Values in this field will match values stored in the AGSRelationshipInfo::keyField
of features participating in the relationship.
|
readnonatomiccopy |
Name of the relationship.
|
readnonatomicassign |
Unique identifier of the related feature table specified by this relationship.
|
readnonatomicassign |
Unique identifier of the relationship.
|
readnonatomicassign |
The ID of the relationship table. Default value is -1.
The relationship table is used in many-to-many and attributed relationships.
|
readnonatomicassign |
Role of the feature table in this relationship.