A structure equivalence policy joins equivalence constraints together to specify how the system should compare two instances of the same concept.
By default the system walks through all the properties and compares each, descending into sub-properties as needed. Each comparison uses any available equivalence definitions for the properties. Comparison of structures with any missing properties will always return
uncertain. For example, two values that have an
optional property, where one instance has the property, and the other does not, would return
uncertain. Otherwise comparison returns
true if and only if all property comparisons return
true. We can modify this default behavior by defining equivalence as part of the concept structure.
See primitive equivalence for information about comparing primitives.
You can learn more about equivalence in Fundamentals documentation.
|As a special case, we can define equivalence rules for geo.GeoPoint properties using the distance-equality constraint, which returns true if two points are within a specified geographic distance of each other|
|Constraint that returns true if the two concepts are equal (all their properties are equal)|
|Constraint that declares that a property must be equal for the equivalence definition to return true|
|Constraint that returns the equivalence result for a specific property|
|Constraint that relaxes the equivalence threshold for float values (primitive type decimal)|
|Constraint that relaxes the equivalence threshold for strings (primitive type name)|
|If a concept extends another concept, you can choose to inherit the equivalence policy of the inherited type by specifying this key|
|The join key evaluates constraints and determines whether to return false, uncertain, or true, depending on the result|
|Never set types equal to each other|
|Modifies the behavior of a join by treating uncertain as true|
|Modifies the behavior of a join by treating uncertain as false|