FDO DataValue Comparison

Overview

There are a number of places in core FDO and Provider source code where data values are compared, which include but are not limited to:

• in the FdoIInsert and FdoIUpdate implementations of non-RDBMS providers that support Property Value Constraints. When a property has a constraint, each property value being inserted or updated is validated against this constraint.
  
• in the FdoIApplySchema implementation of the SDF Provider. This provider does not allow Value constraints, on Properties with data, to be made more restrictive, since the existing data might violate the updated constraint. Checking whether a range constraint is being made more restrictive, involves the comparing of its old and new range endpoints.
  

These data values include property values for features and property constraint values. Comparing data values is not a trivial operation because of the following:

• there are 12 different types of data values. The numeric ones can be compared using basic operators ( >, <, ==, etc. ), but runtime functions are required for strings. For DateTimes each component ( year, month, etc. ) must be compared.
  
• the data values to be compared might be of different types, meaning that type conversion may need to be done before the values can be compared. Some types are not compatible and cannot be compared.
  
• one or both of the data values may be null. A null value cannot be compared to a not-null value even if both have the same data type.
  

Data value comparisons are currently implemented at various other spots in core FDO and the FDO providers. Implementing these conversions at different spots leads to the following problems:

• there is no consistent handling of type comparisons. For example, different parts of FDO might handle null values differently.
  
• code duplication. More expensive maintenance if the same fix has to be applied in multiple places (this can easily happen when the value comparison code is cloned to different places).
  
• more difficult for developers to find the value comparison functions currently available, since these can be in various places.
  

Data values are encapsulated in the FdoDataValue class and its derivations. There is a derivation for each data type supported by FDO. An FDO data type is a scalar type that commonly occurs in the data sources supported by FDO. Examples include integer (8bit, 16bit, 32bit, 64bit), string and datetime.

This document proposes to add a comparison function to FdoDataValue. The function would take a second data value and return the result of comparing the current value to the second one. There would be 4 different possible results:

• current value is greater than second value
  
• both values are equal or both null
  
• current value is less than second value
  
• the two values cannot be compared
  

API Changes

The following function will be added:

FDO_API FdoCompareType FdoDataValue::Compare( FdoDataValue* other );

where the input parameter other is the other value to compare against the current value.

The return values can be one of the following:

!FdoCompareType_Equal: this and the other value are equal or both null
!FdoCompareType_Greater: this value is greater than the other value
!FdoCompareType_Less: this value is less than the other value
!FdoCompareType_Undefined: these two values are different but cannot be compared.

Cases where !FdoCompareType_Undefined happens are:

• their types are incompatible
  
• one value is null and the other value is not
  
• both values are Boolean and one is true and the other is false
  

The following enumeration will be added:

enum FdoCompareType
{
    FdoCompareType_Undefined,
    FdoCompareType_Less,
    FdoCompareType_Greater,
    FdoCompareType_Equal
};

Type Compatibility

See attached document -- FDO_DataValue_Type_Compatibility.pdf

Type Conversions

See attached document -- FDO_DataValue_Type_Compatibility.pdf

Collation by Data Type

This section describes how values of each type will be ordered for comparison purposes.

Boolean: Values will not be ordered. When !FdoBooleanValue::Compare() is passed another FdoBooleanValue it will return:

!FdoCompareType_Equal – if they are equal

!FdoCompareType_Undefined – if they are not equal

Numeric Types ( Byte, Decimal, Double, Int16, Int32, Int64, Single ): Values will be ordered numerically.

DateTime: Values will be ordered from earliest to latest.

String, CLOB: Values will be ordered lexically. TBD: Should collation be a default binary one or the one for the current locale?

BLOB: each pair of bytes from the two values will be compared, starting at the first ones, until the first differing pair of bytes is reached. Comparison will be based on the binary values of these differing bytes. If the end of one BLOB is reached before the other one, the longer BLOB will be considered to be greater than the other BLOB.

Issues

Should string value comparisons be based on current locale?