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 specifies properties to use for testing structure equivalence|
|Constraint that relaxes the equivalence threshold for float values (primitive type decimal)|
|Constraint that relaxes the equivalence threshold for strings (primitive type name)|
|Inherit the equivalent policy from a parent concept|
|Evaluates constraints and determines whether to return false, uncertain, or true, depending on the result|
|Never set types equal to each other|
|A join that only returns false or true, treating values that would be uncertain as true|
|A join that only returns false or true, treating values that would be uncertain as false|