Changes between Version 14 and Version 15 of FDORfc30
- Timestamp:
- 11/21/08 10:18:43 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc30
v14 v15 7 7 8 8 ||RFC Template Version||(1.0)|| 9 ||Submission Date|| (Date/Time submitted)||10 ||Last Modified|| (your name here)[[Timestamp]]||9 ||Submission Date||November 21, 2008|| 10 ||Last Modified||Brent Robinson [[Timestamp]]|| 11 11 ||Author||Brent Robinson|| 12 12 ||RFC Status||draft|| … … 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. 29 29 30 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. 31 32 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: 30 One current 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: 33 31 34 32 ID = 5 35 33 36 34 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()] 35 36 Another 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. 37 37 38 38 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: