Changes between Version 11 and Version 12 of FDORfc30

Timestamp:

11/21/08 09:13:55 (16 years ago)

Author:

brentrobinson

Comment:

--

FDORfc30

@@ -28 +28 @@
 There are a number of places in core FDO and Provider source code where data values are converted from one type to another. These data values include property values for features and property constraint values. Also, as various FDO client applications are written, some of them may also need to do data type conversion. 
 
-One current example is the [http://svn.osgeo.org/fdo/trunk/Fdo/Unmanaged/Inc/Fdo/Commands/Schema/IDescribeSchema.h FdoIDescribeSchema] implementation for the RDBMS providers, which extracts check constraints from SQL expressions obtained from the RDBMS, and converts them into FDO Property Value Constraints. These constraints contain data values that represent ranges or lists of allowed values. The data types determined by the expression parser do not always exactly match the data type for the property that owns the constraint. When the types differ, the data values are converted to the property's data type. 
+One current example is the [http://svn.osgeo.org/fdo/trunk/Fdo/Unmanaged/Inc/Fdo/Commands/Schema/IDescribeSchema.h FdoIDescribeSchema] implementation for the RDBMS providers ( in [http://svn.osgeo.org/fdo/trunk/Utilities/SchemaMgr/Src/Sm/Lp/SchemaCollection.cpp FdoSmLpSchemaCollection::FixDataValueType()]), which extracts check constraints from SQL expressions obtained from the RDBMS, and converts them into FDO Property Value Constraints. These constraints contain data values that represent ranges or lists of allowed values. The data types determined by the expression parser do not always exactly match the data type for the property that owns the constraint. When the types differ, the data values are converted to the property's data type. 
 
 Another example is when an SDF file has a feature class with an int64 identity property called ID, and an FdoISelect is performed with the following string filter:
@@ -34 +34 @@
     ID = 5
 
-When the filter is parsed, the value 5 becomes an int32 value. Since the filter is on the identity property, the SDF provider optimizes the select by doing an indexed lookup. However, for the lookup to work, the value must be converted to the property type (int32->int64). 
+When the filter is parsed, the value 5 becomes an int32 value. Since the filter is on the identity property, the SDF provider optimizes the select by doing an indexed lookup. However, for the lookup to work, the value must be converted to the property type (int32->int64). This conversion is done in [http://svn.osgeo.org/fdo/trunk/Providers/SDF/Src/Provider/SdfQueryOptimizer.cpp SdfQueryOptimizer::ConvertDataValue()] 
 
 Data value type conversions are not always trivial and the supporting runtime functions sometimes differ between Win32 and Linux (e.g. converting between string and int64). Implementing these conversions in different places leads to the following problems: 
@@ -52 +52 @@
 Application and Provider developers also need a certain amount of control over how the conversion is performed, in regards to:
 
- Truncation - how to handle values that are too large for the destination type (e.g. convert 100000 to int16). In most cases, the conversion should fail but there are some cases where truncation is ok. For example, if 100000 is the inclusive maximum for a range constraint, then converting it to max int16 would be ok.
+ Truncation - how to handle values that are too large for the destination type (e.g. convert 100000 to int16). In most cases, the conversion should fail but there are some cases where truncation is ok. For example, if 100000 is the inclusive maximum for a range constraint, then converting it to max int16 (32767) would be ok.
 
  Shifting - how to handle values that lose precision when converted (e.g. convert 1.9 to int32). In some cases, rounding the value is ok. However, if it is a value parsed from an FDO filter string (e.g "ID = 1.9"), then rounding it is not ok since that changes the filter to "ID = 2".