Changes between Version 6 and Version 7 of FDORfc55
- Timestamp:
- 01/14/11 14:31:35 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc55
v6 v7 1 = FDO RFC 55 - Convert FdoDecimal(p,0) datatype to FdoInt32 for SHP Provider =1 = FDO RFC 55 - Convert !FdoDecimal(p,0) datatype to FdoInt32 for SHP Provider = 2 2 3 3 This page contains an change request (RFC) for the FDO Open Source project. … … 28 28 29 29 The motivation is well explained by: 30 Ticket #365 [SHP Provider]: When executing IApplySchema, Int32 properties are converted to Decimal properties30 Ticket #365 [SHP Provider]: When executing IApplySchema, !Int32 properties are converted to Decimal properties 31 31 http://trac.osgeo.org/fdo/ticket/365 32 32 33 >> If you execute an IApplySchema on a SHP connection. Any Int32 properties in any class definitions inside the schema (to be applied) will be converted to Decimal properties once the schema has been applied. This does not happen if the Int32 property happens to be an Identity property. <<33 >> If you execute an IApplySchema on a SHP connection. Any Int32 properties in any class definitions inside the schema (to be applied) will be converted to Decimal properties once the schema has been applied. This does not happen if the !Int32 property happens to be an Identity property. << 34 34 35 For further clarification "will be converted to Decimal properties" refer to FdoDecimal properties.35 For further clarification "will be converted to Decimal properties" refer to !FdoDecimal properties. 36 36 37 Note storing FdoInt32 as Decimals is expected since by specification DBF files natively do not have an integer type, but only DECIMAL(precision, scale) datatype. The same apply to double and single precision datatypes. Hence aFdoInt32 is mapped to a DECIMAL(11, 0) column type.37 Note storing !FdoInt32 as Decimals is expected since by specification DBF files natively do not have an integer type, but only DECIMAL(precision, scale) datatype. The same apply to double and single precision datatypes. Hence a !FdoInt32 is mapped to a DECIMAL(11, 0) column type. 38 38 39 The impact is on Describe Schema when currently a FdoDecimal is returned for a DECIMAL column even in the cases when the scale is zero and most probably the original type was aFdoInt32.39 The impact is on Describe Schema when currently a !FdoDecimal is returned for a DECIMAL column even in the cases when the scale is zero and most probably the original type was a !FdoInt32. 40 40 41 This RFC is required since reading back a FdoInt32 instead of aFdoDecimal is a change in behavior.41 This RFC is required since reading back a !FdoInt32 instead of a !FdoDecimal is a change in behavior. 42 42 43 43 == Proposed Solution == … … 45 45 Modify the FDO SHP provider: 46 46 47 * the DBF to FDO datatype mapping (physical to logical conversion) needs a small refinement. In the case of DECIMAL(precision, scale) check the scale value. When the scale is 0 (zero) then return an FdoInt32 rather than an FdoDecimal. Note SHP doesn't support FdoInt64 or FdoInt16 datatypes therefore the mapping toFdoInt32 is unique.47 * the DBF to FDO datatype mapping (physical to logical conversion) needs a small refinement. In the case of DECIMAL(precision, scale) check the scale value. When the scale is 0 (zero) then return an !FdoInt32 rather than an !FdoDecimal. Note SHP doesn't support !FdoInt64 or !FdoInt16 datatypes therefore the mapping to !FdoInt32 is unique. 48 48 49 49 == Implications == 50 50 51 * In the case of physical DECIMAL(precision, scale) column the corresponding logical FDO property type will be set according to the scale. The caller must expect either a FdoDecimal or aFdoInt32 when reading a SHP schema.51 * In the case of physical DECIMAL(precision, scale) column the corresponding logical FDO property type will be set according to the scale. The caller must expect either a !FdoDecimal or a !FdoInt32 when reading a SHP schema. 52 52 53 * This is a behavior change for the SHP provider. Before this change, SHP would return only FdoDecimal for all numerical FDO types. It would never return anInt32 except for the identity property (which actually is not stored).53 * This is a behavior change for the SHP provider. Before this change, SHP would return only !FdoDecimal for all numerical FDO types. It would never return an !Int32 except for the identity property (which actually is not stored). 54 54 55 * The provider will return a FdoInt32 even for properties which originally were DECIMAL(p, 0). This issue can be mitigated by noting the SHP provider already does silent corrections on the fly in certain cases, like truncating the property names when found too long (both on reading and writing).55 * The provider will return a !FdoInt32 even for properties which originally were DECIMAL(p, 0). This issue can be mitigated by noting the SHP provider already does silent corrections on the fly in certain cases, like truncating the property names when found too long (both on reading and writing). 56 56 57 57 == Test Plan == 58 58 59 * Enhance the unit test and add roundtripping fidelity tests for FdoInt32 properties.59 * Enhance the unit test and add roundtripping fidelity tests for !FdoInt32 properties. 60 60 61 61 == Funding/Resources ==