| 19 | | ||Author||(your name here)|| |
| 20 | | ||RFC Status||(draft, proposed, frozen for vote, adopted, retracted, or rejected)|| |
| 21 | | ||Implementation Status||(pending, under development, completed)|| |
| 22 | | ||Proposed Milestone||(e.g. 1.1, 1.3)|| |
| | 11 | ||Author||Brent Robinson|| |
| | 12 | ||RFC Status||draft|| |
| | 13 | ||Implementation Status||pending|| |
| | 14 | ||Proposed Milestone||3.5|| |
| 36 | | This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be. |
| | 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 | |
| | 30 | One current example is the 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. |
| | 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: |
| | 33 | |
| | 34 | ID = 5 |
| | 35 | |
| | 36 | 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). |
| | 37 | |
| | 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: |
| | 39 | |
| | 40 | • there is no consistent handling of type conversions. For example, different parts of FDO might handle overflows (value is not valid for the destination type) differently |
| | 41 | • code duplication. More expensive maintenance if the same fix has to be applied in multiple places (this can easily happen when the type conversion code is cloned to different places) |
| | 42 | • more difficult for developers to find the type conversion functions currently available, since these can be in various places |
| | 43 | |
| | 44 | Data values are encapsulated in the FdoDataValue class and its derivations. There is a derivation for each data type supported by FDO. Example data types include various integer types (8bit, 16bit, 32bit, 64bit), string and datetime. |
| | 45 | |
| | 46 | The FdoDataValue class effectively provides this type conversion now, by supporting the conversion from strings to other data types and vice-versa. For example, a double can be converted to an int32 by converting it to a string and then to an int32. However, providing a more direct conversion, without converting to and from strings, would provide better performance. It also allows very large or small values to be converted more accurately. |
| | 47 | |
| | 48 | It is also possible to convert between various numeric types through simple casting. However, this leads to source code with sizeable switch statements when converting between two arbitrary data types. |
| | 49 | |
| | 50 | This RFC proposes that data type conversions be encapsulated in new API functions on the FdoDataValue class. |
| | 51 | |
