FDO RFC #30 - DataValue Type Conversion

This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	(Date/Time submitted)
Last Modified	(your name here) Timestamp
Author	Brent Robinson
RFC Status	draft
Implementation Status	pending
Proposed Milestone	3.5
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1

Overview

The purpose of this RFC is to enhance the FDO API to support converting FDO data values between various types.

Motivation

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 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.

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:

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).

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:

• 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 • 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) • more difficult for developers to find the type conversion 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. Example data types include various integer types (8bit, 16bit, 32bit, 64bit), string and datetime.

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.

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.

This RFC proposes that data type conversions be encapsulated in new API functions on the FdoDataValue class.

Proposed Solution

This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, XML schema changes, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed.

Implications

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

Test Plan

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

Funding/Resources

This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.