Changes between Version 24 and Version 25 of FDORfc20


Ignore:
Timestamp:
07/08/08 14:06:15 (17 years ago)
Author:
thomasknoell
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc20

    v24 v25  
    2323== Motivation ==
    2424
    25 This RFC addresses the following objectives:
    26 
    27 '''''Propose enhancements to the FDO capability interfaces enabling applications to eliminate current provider specific handling'''''
    28 
    29 FDO is supposed to provide applications with a set of interfaces allowing the general implementation of tasks without taking into account whether or not the data store is a RDBMS database (Oracle, MySQL, SQL Server) or a file (SHP, SDF). Therefore, an application should not need to implement provider specific processing. However, it was reported that the current capability set is not sufficient enough to achieve this. Hence, some provider specific handling is still required. The following lists an extract of the reported use cases:
    30 
    31     * An application may tessellate arc segments if a provider cannot handle them. To determine whether or not this is the case, the application can use a geometric capability that returns the list of supported geometry shapes a provider can process. If this information does not include arcs, the tessellation must be executed. The exception to this rule is an Oracle data store. BY default, Oracle supports storing arcs unless the current coordinate system is a Lat/Long system. In this case arcs are not supported. FDO does currently not provide any support to handle this case. Therefore, an application would have to implement provider specific processing for it.
    32     * Some providers support only an autogenerated identity (primary key) property while other providers can support either. FDO currently does not indicate on a provider level whether or not this feature is supported.
    33 
    34 Both cases can be solved by introducing new capabilities which will allow for the removal of the provider specific processing.
    35 
    36 
    37 '''''Change the capability interface set to allow the addition of new capabilities without changing the interface set'''''
    38 
    39 The objective here is to simplify the FDO capability interfaces in that the addition of a new capability does not require FDO, providers (if they don't immediately support the new capability) and applications (if they don't use the new capability) to be rebuild.
     25The objective is to simplify the current FDO capability API interface set in that the addition of a new capability does not require FDO, providers (if they don't immediately support the new capability) and applications (if they don't use the new capability) to be rebuild.
    4026
    4127
    4228== Proposals ==
    43 
    44 This section outlines the proposed changes to the FDO capability interfaces related to the objectives to be addressed.
    45 
    46 
    47 === FDO Capability Interface Simplification ===
    4829
    4930Currently, there is a FDO interface for each capability FDO supports. Any change to the capability set requires a new interface to be added to FDO to retrieve the value. As a result, FDO is no longer binary compatible once this is done and requires a re-build of FDO and any provider wanting to use the updated FDO version.
    … …  
    6243    * Strings: These functions return strings. The category includes functions such as ''!GetReservedCharactersForName()''.
    6344
    64 A capability interface class – ''FdoICommand'', ''FdoIConnection'', ''FdoIExpression'', ''FdoIFilter'', ''FdoIGeometry'', ''FdoIRaster'', ''FdoISchema'', ''FdoITopology'' – may have any number of functions of those different categories with the Boolean category containing the most functions.
     45A capability interface class may have any number of functions of those different categories with the Boolean category containing the most functions.
    6546
    6647The simplification of the FDO capability interfaces focuses on those categories as it creates interfaces depending on the expected return type. As a result, a capability interface will be processing a number of capabilities that have the same return type and hence requires the caller to identify the capability for which the value should be returned. In addition, the functions must also be able to indicate to the caller if a provided capability identifier is unknown. Therefore, the signature definition of those new interfaces must have at least two parameters:
    … …  
    8263  public:
    8364
    84    FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability,                   bool *isUnknown) = 0;
    85    FDO_API virtual FdoInt32  GetInt32Capability   (FdoInt32 capability,                   bool *isUnknown) = 0;
    86    FDO_API virtual FdoInt64  GetInt64Capability   (FdoInt32 capability,                   bool *isUnknown) = 0;
    87    FDO_API virtual FdoString *GetStringCapability (FdoInt32 capability,                   bool *isUnknown) = 0;
    88    FDO_API virtual FdoInt32  *GetArrayCapability  (FdoInt32 capability, FdoInt32 &length, bool *isUnknown) = 0;
    89    FDO_API virtual void      *GetObjectCapability (FdoInt32 capability,                   bool *isUnknown) = 0;
     65   FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability,                    bool *isUnknown) = 0;
     66   FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability, FdoString *value,  bool *isUnknown) = 0;
     67   FDO_API virtual FdoInt32  GetInt32Capability   (FdoInt32 capability,                    bool *isUnknown) = 0;
     68   FDO_API virtual FdoInt64  GetInt64Capability   (FdoInt32 capability,                    bool *isUnknown) = 0;
     69   FDO_API virtual FdoString *GetStringCapability (FdoInt32 capability,                    bool *isUnknown) = 0;
     70   FDO_API virtual FdoInt32  *GetArrayCapability  (FdoInt32 capability, FdoInt32  &length, bool *isUnknown) = 0;
     71   FDO_API virtual void      *GetObjectCapability (FdoInt32 capability,                    bool *isUnknown) = 0;
    9072
    9173}  //  FdoICapability
    … …  
    167149  public:
    168150
    169     System::Boolean GetBooleanCapability (System::Int32 capability, System::Boolean *isUnknown);
    170     System::Int32   GetInt32Capability   (System::Int32 capability, System::Boolean *isUnknown);
    171     System::Int64   GetInt64Capability   (System::Int32 capability, System::Boolean *isUnknown);
    172     System::String  *GetStringCapability (System::Int32 capability, System::Boolean *isUnknown);
    173     System::Int32[] GetArrayCapability   (System::Int32 capability, System::Boolean *isUnknown);
    174     System::Object  GetObjectCapability  (System::Int32 capability, System::Boolean *isUnknown);
     151    System::Boolean GetBooleanCapability (System::Int32 capability,                        System::Boolean *isUnknown);
     152    System::Boolean GetBooleanCapability (System::Int32 capability, System::String *value, System::Boolean *isUnknown);
     153    System::Int32   GetInt32Capability   (System::Int32 capability,                        System::Boolean *isUnknown);
     154    System::Int64   GetInt64Capability   (System::Int32 capability,                        System::Boolean *isUnknown);
     155    System::String  *GetStringCapability (System::Int32 capability,                        System::Boolean *isUnknown);
     156    System::Int32[] GetArrayCapability   (System::Int32 capability,                        System::Boolean *isUnknown);
     157    System::Object  GetObjectCapability  (System::Int32 capability,                        System::Boolean *isUnknown);
    175158
    176159}
    … …  
    178161}}}
    179162
    180 As part of the proposed change to the FDO capability interface set, a new enumeration will be added. This new enumeration - ''!FdoCapabilityType'' - contains a list of all currently supported capabilities including the ones added as
    181 a result of this RFC. The following outlines this enumeration:
     163As part of the proposed change to the FDO capability interface set, a new enumeration will be added. This new enumeration - ''!FdoCapabilityType'' - contains a list of all currently supported capabilities (including the one proposed in RFC 24). The following outlines this enumeration:
    182164
    183165{{{
    … …  
    447429
    448430
    449 === Eliminate Provider Specific Processing in Applications ===
    450 
    451 As outlined in the motivation section of this RFC, it has been found that the current set of capabilities is not sufficient enough for applications to avoid implementing provider specific processing. As a result, it is proposed to
    452 add the following new capabilities.
    453 
    454 
    455 ==== Arc Support ====
    456 
    457 An application may tessellate arc segments if a provider cannot handle them. To determine whether or not this is the case, the application can use a geometric capability that returns the list of supported geometry shapes a provider can process. If this information does not include arcs, the tessellation must be executed. The exception to this rule is an Oracle data store. By default, Oracle supports storing arcs unless the current coordinate system is a Lat/Long system. In this case arcs are not supported. FDO does currently not provide any support to handle this case. Therefore, an application would have to implement provider specific processing for it.
    458 
    459 This case will be addressed by a new capability. It allows the user to provide a coordinate system name and returns a boolean flag indicating whether or not arc segments can be stored. In order to do this the new FDO capability interface to return a boolean value must be overwritten with a function that accepts an additional parameter (the coordinate system name). The following outlines the changes to the class ''!FdoICapability''.
    460 
    461 {{{
    462 
    463 #include <Fdo/Connections/Capabilities/CapabilityType.h>
    464 
    465 class FdoICapability : public FdoIDisposable
    466 {
    467 
    468   public:
    469 
    470    FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability,                   bool *isUnknown) = 0;
    471    FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability, FdoString *value, bool *isUnknown) = 0;
    472 
    473    :
    474 
    475 
    476 }  //  FdoICapability
    477 
    478 }}}
    479 
    480 The change to the class FdoICapability requires a change to the corresponding class ''!ICapability'' in the FDO managed code base:
    481 
    482 
    483 {{{
    484 
    485 public __gc __interface ICapability : public System::IDisposable
    486 {
    487 
    488   public:
    489 
    490     System::Boolean GetBooleanCapability (System::Int32 capability,                        System::Boolean *isUnknown);
    491     System::Boolean GetBooleanCapability (System::Int32 capability, System::String *value, System::Boolean *isUnknown);
    492 
    493     :
    494 
    495 }
    496 
    497 }}}
    498 
    499 In addition to those changes the capability identifier ''!FdoCapabilityType_CSSupportsArcs'' will be added to the enumeration ''!FdoCapabilityType'' and the corresponding identifier ''!CapabilityType_CSSupportsArcs'' to the enumeration ''!CapabilityType''.
    500 
    501 
    502 ==== Calculated Property Support ====
    503 
    504 Currently, the FDO capability set does not include a capability with which a provider can indicate whether or not it supports calculated properties. This deficit will be addressed by a new capability. The capability returns a TRUE if calculated properties are supported, FALSE otherwise. To address the capability, the identifier ''!FdoCapabilityType_SupportsCalculatedProperties'' is added to the enumeration ''!FdoCapabilityType'' and ''!CapabilityType_SupportsCalculatedProperties'' to the enumeration ''!CapabilityType''.
    505 
    506 
    507 ==== Writable Identity Property Support ====
    508 
    509 Some providers support only an autogenerated identity (primary key) property while other providers can support either. FDO currently does not provide a capability with nwhich this can be indicated. This deficit will be addressed by a new capability. The capability will return TRUE if a provider does not require autogenerated identity properties only, FALSE otherwise. To address the capability, the identifier ''!FdoCapabilityType_SupportsWritableIdentityProperties'' will be added to the enumeration ''!FdoCapabilityType'' and ''!CapabilityType_SupportsWritableIdentityProperties''to the enumeration ''!CapabilityType''.
    510 
    511 
    512 ==== Multiple Geometry Support ====
    513 
    514 Some providers do not allow different shapes to be stored in the same geometry property. For example, if the geometry in a SHP file is set to store points, multi-point shapes are not allowed. Another example would be if the geometry type are lines, point data cannot be stored.
    515 
    516 Currently, a provider cannot indicate whether or not it can handle a combination of different geometry shapes. This issue will be addressed by a new capability. It will return TRUE if multiple geometry types are supported, FALSE otherwise. To address the capability, the identifier ''!FdoCapabilityType_SupportsMultipleGeometries'' will be added to the enumeration ''!FdoCapabilityType'' and ''!CapabilityType_SupportsMultipleGeometries''to the enumeration
    517 ''!CapabilityType''.
    518 
    519 
    520431== Test Plan ==
    521432