Changes between Version 17 and Version 18 of FDORfc20


Ignore:
Timestamp:
Jun 12, 2008, 4:14:34 PM (16 years ago)
Author:
thomasknoell
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc20

    v17 v18  
    1010||Submission Date|| April 30, 2008 ||
    1111||Last Modified|| Jack Lee [[Timestamp]]||
    12 ||Author||Greg Boone||
     12||Author||Thomas Knoell||
    1313||RFC Status||Draft||
    1414||Implementation Status||Pending||
     
    4747
    4848
    49 == !DataStore Capability Support ==
    50 
    51 Unmanaged
    52 
    53 The change to support both provider and datastore level capabilities is done by adding an overloaded function to each of the top-level FdoIConnection capability functions. The overloaded function will have a ''datastoreLevel'' parameter to specify whether the capabilities are for the provider or for the currently connected datastore. Since the existing function will not be removed, there will be two ways to retrieve the provider capabilites.
    54 
    55 This could be an enum rather than a boolean, although I can’t think of any options that we could add to the enum in the future past these two.
    56 
    57 
    58 Managed
    59 
    60 The existing managed API to retrieve the capabilities is defined as a property. The change to support both provider and datastore level capabilities is done by adding a new function to each of the top-level IConnection capability functions. The new functions will have a ''datastoreLevel'' parameter to specify whether the capabilities are for the provider or for the currently connected datastore. Since the existing property will not be removed, there will be two ways to retrieve the provider capabilites.
    61 
    62 
    63 The table below specifies the changes to the above functions.
    64 
    65 '''New FdoIConnection/IConnection Functions'''
    66 
    67 Unmanaged
    68 {{{
    69 virtual FdoICommandCapabilities *       GetCommandCapabilities (bool datastoreLevel) = 0
    70 virtual FdoIConnectionCapabilities *    GetConnectionCapabilities (bool datastoreLevel) = 0
    71 virtual FdoIExpressionCapabilities *    GetExpressionCapabilities (bool datastoreLevel) = 0
    72 virtual FdoIFilterCapabilities *        GetFilterCapabilities (bool datastoreLevel) = 0
    73 virtual FdoIGeometryCapabilities *      GetGeometryCapabilities (bool datastoreLevel) = 0
    74 virtual FdoIRasterCapabilities *        GetRasterCapabilities (bool datastoreLevel) = 0
    75 virtual FdoISchemaCapabilities *        GetSchemaCapabilities (bool datastoreLevel) = 0
    76 virtual FdoITopologyCapabilities *      GetTopologyCapabilities (bool datastoreLevel) = 0
    77 }}}
    78 
    79 Managed
    80 {{{
    81 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICommandCapabilities* GetCommandCapabilities(System::Boolean datastoreLevel);
    82 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IConnectionCapabilities* GetConnectionCapabilities(System::Boolean datastoreLevel);
    83 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IExpressionCapabilities* GetExpressionCapabilities(System::Boolean datastoreLevel);
    84 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IFilterCapabilities* GetFilterCapabilities(System::Boolean datastoreLevel);
    85 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IGeometryCapabilities* GetGeometryCapabilities(System::Boolean datastoreLevel);
    86 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IRasterCapabilities* GetRasterCapabilities(System::Boolean datastoreLevel);
    87 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ISchemaCapabilities* GetSchemaCapabilities(System::Boolean datastoreLevel);
    88 NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ITopologyCapabilities* GetTopologyCapabilities(System::Boolean datastoreLevel);
    89 }}}
    90 
    91 If datastore level capabilities are chosen, then the results will reflect any limitations that the datastore has around those capabilities. Command capabilities will return a smaller list of supported commands for example if the datastore is read-only. In this case, commands such as Update will not be returned.
    92 
    93 Datastore level capabilities would only be available after connecting to a datastore. Requesting datastore level capabilities before a successful connection will result in an exception.
    94 
    95 Some capabilities such as thread capability would not be different between provider level and datastore level.
    96 
    97 '''Impact of !DataStore Level Capabilities on the Above Capability Sets'''
    98 
    99 ''Command Capabilities''
    100 
    101     * The set of supported commands for a datastore could be less than for the general provider. A provider may support long transaction commands, but a particular datastore may not support them.
    102 
    103 ''Connection Capabilities''
    104 
    105     * Of the connection capabilities, locking and long transactions are ones that typically could be different.
    106 
    107 ''Expression Capabilities''
    108 
    109     * The expression types supported typically would not change, although the list of supported functions could be different, e.g. ODBC sources could have different sets of supported functions.
    110 
    111 ''Filter Capabilities''
    112 
    113     * As with expressions, these typically would not change, although there could be cases where spatial filters could be more limited.
    114 
    115 ''Geometry Capabilities''
    116 
    117     * At this time, this capability would not change for a datastore. However, in the future, different ODBC source could have different capabilities here (currently only point geometry is supported for all ODBC sources), or more advanced geometries may be available with future versions of the Oracle server where the Oracle provider can connect to different Oracle versions.
    118 
    119 ''Raster Capabilities''
    120 
    121     * Different sources could support different data models.
    122 
    123 ''Schema Capabilities''
    124 
    125     * At the datastore level, different sources could have different limitations, e.g. different versions of Oracle server or SQL Server, or different ODBC sources.
    126 
    127 == Issues ==
    128 
    129 How much datastore specific limitations can the ODBC provider determine through the ODBC API? Is it capable enough to support the additional schema capabilities specified in this document? Not all odbc providers support all the ODBC capabilities to determine schema information.
     49== Proposals ==
     50
     51This section outlines the proposed changes to the FDO capability interfaces related to the three objectives to be addressed.
     52
     53
     54=== FDO Capability Interface Simplification ===
     55
     56Currently, 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.
     57
     58The aim of this requirement is to address this issue. The idea is to have a simplified set of capability interfaces that allows retrieving different capability values where the capability for which the value is to be returned is indicated by an identifier. As a result, adding a new capability would not require the addition of a new interface.
     59
     60All capability functions can be categorized as outlined next:
     61
     62    * Boolean: These functions return a flag indicating whether or not a capability is supported. The category includes routines such as !SupportsLocking(), !SupportsCompositeId() or !SupportsAutoIdGeneration().
     63    * Enumerates: These functions return an identifier from an enumeration. The category includes routines such as !GetThreadCapability().
     64    * Array of enumerated values: These functions return an array of values from an enumeration and the number of elements in that array. The category includes routines such as !GetSpatialContextTypes() or !GetLockTypes().
     65    * Collection: These functions return a collection of complex objects. The category includes routines such as !GetFunctions().
     66    * Bit-mask values: These functions return a bit-mask value of enumerated values. The category includes routines such as !GetDimensionality().
     67    * Capability based numbers: These functions take a capability identifier and return the corresponding capability value. The category includes routines such as !GetMaximumDataValueLength() or !GetNameSizeLimit().
     68    * Numbers: These functions return number values of different types. The category includes func-tions such as !GetMaximumDecimalPrecision() or !GetMaximumDecimalScale().
     69    * Strings: These functions return strings. The category includes functions such as !GetReservedCharactersForName().
     70
     71A 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.
     72
     73The simplification of the FDO capability interfaces focuses on those categories as it creates interfaces depending on the expected return type. The number of parameters for those functions is at least one which identifies the capability for which the value is requested. Depending on the category, there may be the need for additional parameters – for example, the function returning an array of enumerated values also has to return the number of entries in that array.
     74
     75The new capability interfaces will be defined in a new class - FdoICapability - that resides in the directory Fdo\Unmanaged\Inc\Fdo\Connections\Capabilities. The following outlines the class definition:
     76
     77{{{
     78
     79#include <Fdo/Connections/Capabilities/CapabilityType.h>
     80
     81class FdoICapability : public FdoIDisposable
     82{
     83
     84  public:
     85
     86   FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability, bool      default ) = 0;
     87   FDO_API virtual FdoInt32  GetInt32Capability   (FdoInt32 capability, FdoInt32  default ) = 0;
     88   FDO_API virtual FdoInt64  GetInt64Capability   (FdoInt32 capability, FdoInt64  default ) = 0;
     89   FDO_API virtual FdoString *GetStringCapability (FdoInt32 capability, FdoString *default) = 0;
     90   FDO_API virtual FdoInt32  *GetArrayCapability  (FdoInt32 capability, FdoInt32  &length ) = 0;
     91   FDO_API virtual OBJ       *GetObjectCapability (FdoInt32 capability                    ) = 0;
     92
     93}  //  FdoICapability
     94
     95}}}
     96
     97With the introduction of the class ''FdoICapability'', all other capability classes – ''FdoICommand'', ''FdoIConnection'', ''FdoIExpression'', ''FdoIFilter'', ''FdoIGeometry'', ''FdoIRaster'', ''FdoISchema'', ''FdoITopology'' – become obsolete. This requires a change to the class FdoIConnection that provides access to the capabilities. That class needs a new interface to get the capabilities:
     98
     99{{{
     100
     101FDO_API virtual FdoICapability *GetCapability(bool datastoreLevel = false) = 0;
     102
     103}}}
     104
     105A corresponding change will also be made in the FDO managed code base:
     106
     107{{{
     108
     109...
     110BEGIN_NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES
     111...
     112public __gc __interface ICapability;
     113...
     114END_NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES
     115
     116...
     117
     118NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICapability *GetCapability(System::Boolean datastoreLevel);
     119
     120...
     121
     122}}}
     123
     124Although the new class ''FdoICapability'' will make the other FDO capability classes obsolete, there is no plan to depricate those classes at this point and applications may still use their interfaces although it is expected that the new FDO capability interfaces would be used instead.
     125
     126The class ''FdoICapability'' has generalized interfaces for all return type categories the current set of capability interfaces return. It is feasable to add capability interfaces for all data types that FDO supports in preparation for additional capabilities that may be added at a later stage using those data types. However, the ones currently listed should cover most, if not all of the cases and hence the addition of interfaces for different FDO types is not planned.
     127
     128The implementation of the new interfaces also requires some error handling in case an interface is called with a capability identifier that is invalid in this case (for example, call interface !GetObjectCapability and pass in a capability identifier that returns a boolean value). The initial concept called for the throwing of an exception but this may be difficult to handle for any application. Therefore, the proposed solution allows the caller to provide a default value that is returned in case the requested capability is not found within the function. The exception to this rule are the interfaces to return pointers which will return a NULL pointer if the request is invalid.
     129
     130The simplification of the capability interfaces also affects code using it. This is especially the case for the new interfaces that return an array of enumerated values or a collection. Because of the generalization, the interfaces have to return a neutral data rather than a specific type as it is the case with the original interfaces. This requires the caller to cast the returned object to the expected type. The following shows an example of the old and new style request for a capability that returns an array of enumerated values.
     131
     132{{{
     133
     134Old Style Call
     135
     136FdoPtr<FdoISchemaCapabilities> schemaCapabilities =
     137                                  connection->GetSchemaCapabilities();
     138FdoInt32 listCount;
     139FdoDataType *supportedDataTyes =
     140       schemaCapabilities->GetSupportedAutoGeneratedTypes(listCount);
     141
     142
     143New Style Call
     144
     145FdoPtr<FdoICapability> capability =
     146                                  connection->GetCapability();
     147FdoInt32 listCount;
     148FdoDataType *supportedDataTyes =
     149            (FdoDataType *)capability->GetArrayCapability(
     150                                       FdoCapabilityType_DataTypes,
     151                                       listCount);
     152
     153}}}
     154
     155The change to the unmanaged code requires a corresponding change to the managed code. The class ''ICapability'' will be added at Fdo\Managed\Src\OSGeo\FDO\Connections\Capabilities (file mgICapability.h). The following outlines this new class:
     156
     157{{{
     158
     159public __gc __interface ICommandCapabilities : public System::IDisposable
     160{
     161
     162  public:
     163
     164    System::Boolean GetBooleanCapability (System::Int32 capability, System::Boolean default);
     165    System::Int32   GetInt32Capability   (System::Int32 capability, System::In32    default);
     166    System::Int64   GetInt64Capability   (System::Int32 capability, System::Int64   default);
     167    System::String  *GetStringCapability (System::Int32 capability, System::String  *default);
     168    System::Int32[] GetArrayCapability   (System::Int32 capability);
     169    System::Object  GetObjectCapability  (System::Int32 capability);
     170
     171}
     172
     173}}}
     174
     175As 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 a result of this RFC. The following outlines this enumeration:
     176
     177{{{
     178
     179
     180enum FdoCapabilityType
     181{
     182  // Command Capabilities
     183
     184  FdoCapabilityType_CommandList,
     185  FdoCapabilityType_SupportsParameters,
     186  FdoCapabilityType_SupportsTimeout,
     187  FdoCapabilityType_SupportsSelectExpressions,
     188  FdoCapabilityType_SupportsSelectFunctions,
     189  FdoCapabilityType_SupportsSelectDistinct(),
     190  FdoCapabilityType_SupportsSelectOrdering(),
     191  FdoCapabilityType_SupportsSelectGrouping(),
     192
     193  // Connection Capabilities
     194
     195  FdoCapabilityType_ThreadCapability,
     196  FdoCapabilityType_SpatialContextTypes,
     197  FdoCapabilityType_LockTypes,
     198  FdoCapabilityType_SupportsLocking,
     199  FdoCapabilityType_SupportsTimeout,
     200  FdoCapabilityType_SupportsTransactions,
     201  FdoCapabilityType_SupportsLongTransactions,
     202  FdoCapabilityType_SupportsSQL,
     203  FdoCapabilityType_SupportsConfiguration,
     204  FdoCapabilityType_SupportsMultipleSpatialContexts,
     205  FdoCapabilityType_SupportsCSysWKTFromCSysName,
     206  FdoCapabilityType_SupportsWrite,
     207  FdoCapabilityType_SupportsMultiUserWrite,
     208  FdoCapabilityType_SupportsFlush,
     209
     210  // Expression Capabilities
     211
     212  FdoCapabilityType_ExpressionTypes,
     213
     214
     215  // Filter Capabilities
     216
     217  FdoCapabilityType_ConditionTypes,
     218  FdoCapabilityType_SpatialOperations,
     219  FdoCapabilityType_DistanceOperations,
     220  FdoCapabilityType_SupportsGeodesicDistance,
     221  FdoCapabilityType_SupportsNonLiteralGeometricOperations,
     222
     223  // Geometry Capabilities
     224
     225  FdoCapabilityType_GeometryTypes,
     226  FdoCapabilityType_GeometryComponentTypes,
     227  FdoCapabilityType_Dimensionalities,
     228
     229// Raster Capabilities
     230
     231  FdoCapabilityType_SupportsRaster,
     232  FdoCapabilityType_SupportsStitching,
     233  FdoCapabilityType_SupportsSubsampling,
     234  FdoCapabilityType_SupportsDataModel,
     235
     236  // Schema Capabilities
     237
     238  FdoCapabilityType_ClassTypes,
     239  FdoCapabilityType_DataTypes,
     240  FdoCapabilityType_SupportedAutoGeneratedTypes,
     241  FdoCapabilityType_SupportedIdentityPropertyTypes,
     242  FdoCapabilityType_MaximumDataValueLength_String,
     243  FdoCapabilityType_MaximumDataValueLength_BLOB,
     244  FdoCapabilityType_MaximumDataValueLength_CLOB,
     245  FdoCapabilityType_MaximumDataValueLength_Decimal,
     246  FdoCapabilityType_MaximumDataValueLength_Boolean,
     247  FdoCapabilityType_MaximumDataValueLength_Byte,
     248  FdoCapabilityType_MaximumDataValueLength_DateTime,
     249  FdoCapabilityType_MaximumDataValueLength_Double,
     250  FdoCapabilityType_MaximumDataValueLength_Int16,
     251  FdoCapabilityType_MaximumDataValueLength_Int32,
     252  FdoCapabilityType_MaximumDataValueLength_Int64,
     253  FdoCapabilityType_MaximumDataValueLength_Single,
     254  FdoCapabilityType_MaximumDecimalPrecision,
     255  FdoCapabilityType_MaximumDecimalScale,
     256  FdoCapabilityType_NameSizeLimit_Datastore,
     257  FdoCapabilityType_NameSizeLimit_Schema,
     258  FdoCapabilityType_NameSizeLimit_Class,
     259  FdoCapabilityType_NameSizeLimit_Property,
     260  FdoCapabilityType_NameSizeLimit_Description,
     261  FdoCapabilityType_ReservedCharactersForName,
     262  FdoCapabilityType_SupportsAssociationProperties,
     263  FdoCapabilityType_SupportsAutoIdGeneration,
     264  FdoCapabilityType_SupportsCalculatedProperties,
     265  FdoCapabilityType_SupportsCompositeId,
     266  FdoCapabilityType_SupportsCompositeUniqueValueConstraints,
     267  FdoCapabilityType_SupportsDataStoreScopeUniqueIdGeneration,
     268  FdoCapabilityType_SupportsDefaultValue,
     269  FdoCapabilityType_SupportsExclusiveValueRangeConstraints,
     270  FdoCapabilityType_SupportsInclusiveValueRangeConstraints,
     271  FdoCapabilityType_SupportsInheritance,
     272  FdoCapabilityType_SupportsMultipleSchemas,
     273  FdoCapabilityType_SupportsNetworkModel,
     274  FdoCapabilityType_SupportsNullValueConstraints,
     275  FdoCapabilityType_SupportsObjectProperties,
     276  FdoCapabilityType_SupportsSchemaModification,
     277  FdoCapabilityType_SupportsSchemaOverrides,
     278  FdoCapabilityType_SupportsUniqueValueConstraints,
     279  FdoCapabilityType_SupportsValueConstraintsList,
     280  FdoCapabilityType_SupportsWritableIdentityProperties,
     281
     282  // Topology Capabilities
     283
     284  FdoCapabilityType_SupportsTopology,
     285  FdoCapabilityType_SupportsTopologicalHierarchy,
     286  FdoCapabilityType_BreaksCurveCrossingsAutomatically,
     287  FdoCapabilityType_ActivatesTopologyByArea,
     288  FdoCapabilityType_ConstrainsFeatureMovements,
     289
     290}  //  enum FdoCapabilityType
     291
     292}}}
     293
     294The new enumeration will reside in the directory Fdo\Unmanaged\Inc\Fdo\Connections\Capabilities. A corresponding definition - ''!CapabilityType'' - will be added to the managed code (Fdo\Managed\Src\OSGeo\FDO\Connections\Capabilities):
     295
     296{{{
     297
     298public __value enum CapabilityType
     299{
     300  // Command Capabilities
     301
     302  CapabilityType_CommandList,
     303  CapabilityType_SupportsParameters,
     304  CapabilityType_SupportsTimeout,
     305  CapabilityType_SupportsSelectExpressions,
     306  CapabilityType_SupportsSelectFunctions,
     307  CapabilityType_SupportsSelectDistinct(),
     308  CapabilityType_SupportsSelectOrdering(),
     309  CapabilityType_SupportsSelectGrouping(),
     310
     311  // Connection Capabilities
     312
     313  CapabilityType_ThreadCapability,
     314  CapabilityType_SpatialContextTypes,
     315  CapabilityType_LockTypes,
     316  CapabilityType_SupportsLocking,
     317  CapabilityType_SupportsTimeout,
     318  CapabilityType_SupportsTransactions,
     319  CapabilityType_SupportsLongTransactions,
     320  CapabilityType_SupportsSQL,
     321  CapabilityType_SupportsConfiguration,
     322  CapabilityType_SupportsMultipleSpatialContexts,
     323  CapabilityType_SupportsCSysWKTFromCSysName,
     324  CapabilityType_SupportsWrite,
     325  CapabilityType_SupportsMultiUserWrite,
     326  CapabilityType_SupportsFlush,
     327
     328  // Expression Capabilities
     329
     330  CapabilityType_ExpressionTypes,
     331
     332
     333  // Filter Capabilities
     334
     335  CapabilityType_ConditionTypes,
     336  CapabilityType_SpatialOperations,
     337  CapabilityType_DistanceOperations,
     338  CapabilityType_SupportsGeodesicDistance,
     339  CapabilityType_SupportsNonLiteralGeometricOperations,
     340
     341  // Geometry Capabilities
     342
     343  CapabilityType_GeometryTypes,
     344  CapabilityType_GeometryComponentTypes,
     345  CapabilityType_Dimensionalities,
     346
     347// Raster Capabilities
     348
     349  CapabilityType_SupportsRaster,
     350  CapabilityType_SupportsStitching,
     351  CapabilityType_SupportsSubsampling,
     352  CapabilityType_SupportsDataModel,
     353
     354  // Schema Capabilities
     355
     356  CapabilityType_ClassTypes,
     357  CapabilityType_DataTypes,
     358  CapabilityType_SupportedAutoGeneratedTypes,
     359  CapabilityType_SupportedIdentityPropertyTypes,
     360  CapabilityType_MaximumDataValueLength_String,
     361  CapabilityType_MaximumDataValueLength_BLOB,
     362  CapabilityType_MaximumDataValueLength_CLOB,
     363  CapabilityType_MaximumDataValueLength_Decimal,
     364  CapabilityType_MaximumDataValueLength_Boolean,
     365  CapabilityType_MaximumDataValueLength_Byte,
     366  CapabilityType_MaximumDataValueLength_DateTime,
     367  CapabilityType_MaximumDataValueLength_Double,
     368  CapabilityType_MaximumDataValueLength_Int16,
     369  CapabilityType_MaximumDataValueLength_Int32,
     370  CapabilityType_MaximumDataValueLength_Int64,
     371  CapabilityType_MaximumDataValueLength_Single,
     372  CapabilityType_MaximumDecimalPrecision,
     373  CapabilityType_MaximumDecimalScale,
     374  CapabilityType_NameSizeLimit_Datastore,
     375  CapabilityType_NameSizeLimit_Schema,
     376  CapabilityType_NameSizeLimit_Class,
     377  CapabilityType_NameSizeLimit_Property,
     378  CapabilityType_NameSizeLimit_Description,
     379  CapabilityType_ReservedCharactersForName,
     380  CapabilityType_SupportsAssociationProperties,
     381  CapabilityType_SupportsAutoIdGeneration,
     382  CapabilityType_SupportsCalculatedProperties,
     383  CapabilityType_SupportsCompositeId,
     384  CapabilityType_SupportsCompositeUniqueValueConstraints,
     385  CapabilityType_SupportsDataStoreScopeUniqueIdGeneration,
     386  CapabilityType_SupportsDefaultValue,
     387  CapabilityType_SupportsExclusiveValueRangeConstraints,
     388  CapabilityType_SupportsInclusiveValueRangeConstraints,
     389  CapabilityType_SupportsInheritance,
     390  CapabilityType_SupportsMultipleGeometries,
     391  CapabilityType_SupportsMultipleSchemas,
     392  CapabilityType_SupportsNetworkModel,
     393  CapabilityType_SupportsNullValueConstraints,
     394  CapabilityType_SupportsObjectProperties,
     395  CapabilityType_SupportsSchemaModification,
     396  CapabilityType_SupportsSchemaOverrides,
     397  CapabilityType_SupportsUniqueValueConstraints,
     398  CapabilityType_SupportsValueConstraintsList,
     399  CapabilityType_SupportsWritableIdentityProperties,
     400
     401  // Topology Capabilities
     402
     403  CapabilityType_SupportsTopology,
     404  CapabilityType_SupportsTopologicalHierarchy,
     405  CapabilityType_BreaksCurveCrossingsAutomatically,
     406  CapabilityType_ActivatesTopologyByArea,
     407  CapabilityType_ConstrainsFeatureMovements,
     408
     409}  //  CapabilityType
     410
     411}}}
     412
     413Like the command enumeration, the capability enumeration can be extended by the providers to add their own capabilities if this is required.
     414
     415
     416=== Data Store Level Capability Support ===
     417
     418To support both, provider and data store level capabilities, the parameter list of the functions defined for the FdoIConnection interface that provide access to the capabilities will be changed. All functions will get an optional boolean parameter that defines the capability level to be requested. The following shows the proposed changes:
     419
     420{{{
     421
     422FDO_API virtual FdoICommandCapabilities    *GetCommandCapabilities    (bool datastoreLevel = false) = 0;
     423FDO_API virtual FdoIConnectionCapabilities *GetConnectionCapabilities (bool datastoreLevel = false) = 0;
     424FDO_API virtual FdoIExpressionCapabilities *GetExpressionCapabilities (bool datastoreLevel = false) = 0;
     425FDO_API virtual FdoIFilterCapabilities     *GetFilterCapabilities     (bool datastoreLevel = false) = 0;
     426FDO_API virtual FdoIGeometryCapabilities   *GetGeometryCapabilities   (bool datastoreLevel = false) = 0;
     427FDO_API virtual FdoIRasterCapabilities     *GetRasterCapabilities     (bool datastoreLevel = false) = 0;
     428FDO_API virtual FdoISchemaCapabilities     *GetSchemaCapabilities     (bool datastoreLevel = false) = 0;
     429FDO_API virtual FdoITopologyCapabilities   *GetTopologyCapabilities   (bool datastoreLevel = false) = 0;
     430FDO_API virtual FdoICapability             *GetCapability             (bool datastoreLevel = false) = 0;
     431
     432}}}
     433
     434By default the optional parameter is set to FALSE, hence not changing the current behavior. Data store level capabilities are available only after a fully connection to a data store has been established. If requested before, an exception will be issued.
     435
     436The changes to the unmanaged code requires a corresponding change to the managed code. There, new interfaces will be defined to reflect the parameter change in the unmanaged code. The following outlines the necessary changes:
     437
     438{{{
     439
     440NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICommandCapabilities    *GetCommandCapabilities    (System::Boolean datastoreLevel);
     441NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IConnectionCapabilities *GetConnectionCapabilities (System::Boolean datastoreLevel);
     442NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IExpressionCapabilities *GetExpressionCapabilities (System::Boolean datastoreLevel);
     443NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IFilterCapabilities     *GetFilterCapabilities     (System::Boolean datastoreLevel);
     444NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IGeometryCapabilities   *GetGeometryCapabilities   (System::Boolean datastoreLevel);
     445NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IRasterCapabilities     *GetRasterCapabilities     (System::Boolean datastoreLevel);
     446NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ISchemaCapabilities     *GetSchemaCapabilities     (System::Boolean datastoreLevel);
     447NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ITopologyCapabilities   *GetTopologyCapabilities   (System::Boolean datastoreLevel);
     448NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICapability             *GetCapability             (System::Boolean datastoreLevel);
     449
     450}}}
     451
     452If data store level capabilities are chosen, then the results will reflect any limitations that the data store has around those capabilities. For example, the command capabilities will return a smaller list of supported commands if the datastore is read-only. In this case, commands such as Update will not be returned. Other capabilities, like the threat related capabilities, will remain unchanged from the provider level values.
     453
     454It is anticipated that the most impact of the data store level capabilities will be with the ODBC provider. At the same time, the ODBC provider also represents the biggest unknown as it is not yet known how much data store specific limitations the ODBC provider can determine through the ODBC API.
     455
     456
     457=== Eliminate Provider Specific Processing in Applications ===
     458
     459As outlined in the motivation section of this RFC, applications like Autodesk Map 3D, !MapGuide and Bulk Copy implement provider specific processing because the required information is currently not available via FDO capabilities. It is one of the objectives of this RFC to change this. The following describes the use cases that have been identified within this context and how they will be addressed.
     460
     461
     462==== Arc Support ====
     463
     464When checking in objects in Map, any arc segments that may be defined with the object’s geometry property will be tessellated if the target provider cannot store arc segments. In general, this decision is made by determining whether or not the arc geometry type is listed as a supported type in the geometry capabilities.
     465
     466The exception to this rule is the Oracle provider. By default, Oracle will support the storage of arc segments unless the current coordinate system is a Lat/Long system in which case arc segments need to be tessellated. The provider specific processing in Map can be eliminated if a capability indicating whether or not arc segments can be stored is added. Such a new capability will be added to the set of geometry capabilities. The function signature is outlined next:
     467
     468'''''bool !SupportsArcSegmentStorage (!FdoString *wktCoordinateSystemName);'''''
     469
     470
     471==== Calculated Property Support ====
     472
     473Currently, Autodesk Map 3D allows users to define calculated properties even if the underlying provider does not support this feature. If used, Map will issue an exception in such a case. The new capability will indicate whether or not a provider supports calculated properties and hence make the corresponding functionality available only if the provider does.
     474
     475The new capability will be addressed with the new capability interface. The capability identifier will be ''!CapabilityType_SupportsCalculatedProperties''.
     476
     477
     478==== Writable Identity Property Support ====
     479
     480Bulk Copy has a provider dependent implementation to determine whether or not a provider supports writing to identity properties. To eliminate this specific handling a new capability - ''!CapabilityType_SupportsWritableIdentityProperties'' - will be added. The new capability is addressed via the new capability interfaces.
     481
     482
     483==== Multiple Geometry Support ====
     484
     485There are two parts to this item:
     486
     487    * A new capability - ''!CapabilityType_SupportsMultipleGeometries'' - will be added with which a provider can indicate whether or not it allows the user to defined multiple geometry types for a geometry property. For example, SHP does not allow to store point and line shapes in the same data store; It can only either one of them.
     488    * Another change affects the Schema Editor in Autodesk Map 3D. The Schema Editor currently allows the user to pick geometric types in any combination to be assigned with the class geometry property. The geometric types are point, line and polygone and are not fine-grained enough to reflect the different shapes a provider can support. FDO already contains such a fine-grained definition of shape types - the geometry types. The geometry types include ''!FdoGeometryType_Point'', ''!FdoGeometryType_LineString'', ''!FdoGeometryType_Polygon'', ''!FdoGeometryType_MultiPoint'', ''!FdoGeometryType_MultiLineString'', ''!FdoGeometryType_MultiPolygon'', ''!FdoGeometryType_MultiGeometry'', ''!FdoGeometryType_CurveString'', ''!FdoGeometryType_CurvePolygon'', ''!FdoGeometryType_MultiCurveString'' and ''!FdoGeometryType_MultiCurvePolygon''. The Schema Editor will be modified to offer those types rather than the current geometric types for the user to pick from. In addition the Schema Editor will use the new capability introduced with this use case to control the selection process.
     489
     490
     491=== Optimization ===
     492
     493One use case was submitted that requested new capabilities to better control the building of a FDO filter. In this specific use case, the filter was build with multile use of the ''!FdoFilter::Combine()'' interface to combine different parts of a filter via the ''OR'' operation. The provided information described that the execution of a select command will fail on some providers if the number of those sub filters excceeds a certain limit. The request was for a new capability that would indicate how many sub-filters can be combined within a provider.
     494
     495Investigation into this use case, however, showed that there is an issue with the process that transforms a filter to a SQL statement. If a node in the tree is reached that combines two sub-filters then the process does not look at the sub-filters to determine if it is required to nest them but rather goes ahead and nests them anyway. This way, the resulting SQL statement contains a deep nesting of sub filters. The following demonstrates this on a small scale:
     496
     497{{{
     498
     499Filter:
     500
     501  a = 1 or a = 2 or a = 3 or a = 4
     502
     503Generated SQL statement:
     504
     505  ((((a = 1) or (a = 2)) or (a = 3)) or (a = 4))
     506
     507}}}
     508
     509Because of the highly nested SQL statement, some providers like ODBC and SQL Server may not be able to handle the complexity and issue an exception.
     510
     511The nesting in general is valid but not always - like in the above example - necessary. This will be addressed as part of this RFC and optimized. The process will be modified to nest sub filters if this is not required. For the above example, this will result in the following SQL statement:
     512
     513{{{
     514
     515Filter:
     516
     517  a = 1 or a = 2 or a = 3 or a = 4
     518
     519Generated SQL statement:
     520
     521  (a = 1) or (a = 2) or (a = 3) or (a = 4)
     522
     523}}}
     524
     525Once the nesting is eliminated the originally reported issue no longer appears. As a result there is no need for additional capabilities.
     526
    130527
    131528== Test Plan ==
    132529
    133 Existing unit tests will be enhanced to test all changes.
     530Existing unit tests will be enhanced and new unit tests added to test all changes.
    134531
    135532== Funding/Resources ==
    136533
    137534Autodesk to provide resource / funding to implement the feature for the affected providers.
    138 
    139