wiki:FDORfc20

Context Navigation

Version 18 (modified by thomasknoell, 17 years ago) ( diff )
--

FDO RFC 20 - Enhanced Capabilities Support

This page contains an change request (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	April 30, 2008
Last Modified	Jack Lee Timestamp
Author	Thomas Knoell
RFC Status	Draft
Implementation Status	Pending
Proposed Milestone	3.4.0.0
Assigned PSC guide(s)	Greg Boone
Voting History	(vote date)
+1
+0
-0
-1

Motivation

This RFC addresses the following objectives:

Propose enhancements to the FDO capability interfaces enabling applications to eliminate current provider specific handling

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:

In Autodesk Map 3D, arc elements are tessellated if the target provider cannot store arc segments. The decision on whether or not a provider supports arc handling is based on the geometry types a provider supports. The exception to this rule is Oracle. Oracle by default supports the storing of arc segments unless the current coordinate system is a Lat/Long system in which case arcs are not supported. The provider specific handling in the application is addressing this issue by first identifying whether or not Oracle is actually the target and then determining if the storing of arcs is supported based on the current coordinate system.
The utility Bulk Copy has a number of provider specific processes. One of them is to determine whether or not the target provider supports writable identity properties.

In any case, the addition of a new capability can eliminate the provider specific handling currently implemented.

Introduce the support for data store level capabilities (currently, only provider level capabilities are available)

There are cases where a provider may indicate the support of a capability when in fact the data store the provider connects to is not capable of actually supporting it. For example, a provider may indicate that it supports locking or writing to a data store although the data store my not be able to handle locking or has a read-only flag being set and hence writing to it would not be possible. Another example would be the ODBC provider. Currently, the capabilities indicate to support almost all of the functionality. However, since the provider can connect to a variaty of different data sources (from Excel and Access to various RDBMS'), the capabilities may be different dependening on the source the provider connects to.

As a result, it is not sufficient enough to just report provider level capabilities; it is also needed to report data store level capabilities. Data store level capabilities would be available only once a provider has a fully formed connection established to a data store.

Change the capability interface set to allow the addition of new capabilities without changing the interface set

To simplify capability handling as the FDO API evolves, the possibility of introducing a FDO capability interface change will be evaluated that would see the FDO API use constants to identify capabilities supported by its providers. This will make it easier to add new capabilities without changing the API every time a need arises to add a new capability.

Proposals

This section outlines the proposed changes to the FDO capability interfaces related to the three objectives to be addressed.

FDO Capability Interface Simplification

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

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

All capability functions can be categorized as outlined next:

Boolean: These functions return a flag indicating whether or not a capability is supported. The category includes routines such as SupportsLocking(), SupportsCompositeId() or SupportsAutoIdGeneration().
Enumerates: These functions return an identifier from an enumeration. The category includes routines such as GetThreadCapability().
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().
Collection: These functions return a collection of complex objects. The category includes routines such as GetFunctions().
Bit-mask values: These functions return a bit-mask value of enumerated values. The category includes routines such as GetDimensionality().
Capability based numbers: These functions take a capability identifier and return the corresponding capability value. The category includes routines such as GetMaximumDataValueLength() or GetNameSizeLimit().
Numbers: These functions return number values of different types. The category includes func-tions such as GetMaximumDecimalPrecision() or GetMaximumDecimalScale().
Strings: These functions return strings. The category includes functions such as GetReservedCharactersForName().

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.

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

The 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:

#include <Fdo/Connections/Capabilities/CapabilityType.h>

class FdoICapability : public FdoIDisposable
{

  public:

   FDO_API virtual bool      GetBooleanCapability (FdoInt32 capability, bool      default ) = 0;
   FDO_API virtual FdoInt32  GetInt32Capability   (FdoInt32 capability, FdoInt32  default ) = 0;
   FDO_API virtual FdoInt64  GetInt64Capability   (FdoInt32 capability, FdoInt64  default ) = 0;
   FDO_API virtual FdoString *GetStringCapability (FdoInt32 capability, FdoString *default) = 0;
   FDO_API virtual FdoInt32  *GetArrayCapability  (FdoInt32 capability, FdoInt32  &length ) = 0;
   FDO_API virtual OBJ       *GetObjectCapability (FdoInt32 capability                    ) = 0;

}  //  FdoICapability

With 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:

FDO_API virtual FdoICapability *GetCapability(bool datastoreLevel = false) = 0;

A corresponding change will also be made in the FDO managed code base:

...
BEGIN_NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES
...
public __gc __interface ICapability;
...
END_NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES

...

NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICapability *GetCapability(System::Boolean datastoreLevel);

...

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

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

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

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

Old Style Call

FdoPtr<FdoISchemaCapabilities> schemaCapabilities =
                                  connection->GetSchemaCapabilities();
FdoInt32 listCount;
FdoDataType *supportedDataTyes =
       schemaCapabilities->GetSupportedAutoGeneratedTypes(listCount);


New Style Call

FdoPtr<FdoICapability> capability =
                                  connection->GetCapability();
FdoInt32 listCount;
FdoDataType *supportedDataTyes =
            (FdoDataType *)capability->GetArrayCapability(
                                       FdoCapabilityType_DataTypes,
                                       listCount);

The 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:

public __gc __interface ICommandCapabilities : public System::IDisposable
{

  public:

    System::Boolean GetBooleanCapability (System::Int32 capability, System::Boolean default);
    System::Int32   GetInt32Capability   (System::Int32 capability, System::In32    default);
    System::Int64   GetInt64Capability   (System::Int32 capability, System::Int64   default);
    System::String  *GetStringCapability (System::Int32 capability, System::String  *default);
    System::Int32[] GetArrayCapability   (System::Int32 capability);
    System::Object  GetObjectCapability  (System::Int32 capability);

}

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 a result of this RFC. The following outlines this enumeration:


enum FdoCapabilityType
{
  // Command Capabilities

  FdoCapabilityType_CommandList,
  FdoCapabilityType_SupportsParameters,
  FdoCapabilityType_SupportsTimeout,
  FdoCapabilityType_SupportsSelectExpressions,
  FdoCapabilityType_SupportsSelectFunctions,
  FdoCapabilityType_SupportsSelectDistinct(),
  FdoCapabilityType_SupportsSelectOrdering(),
  FdoCapabilityType_SupportsSelectGrouping(),

  // Connection Capabilities

  FdoCapabilityType_ThreadCapability,
  FdoCapabilityType_SpatialContextTypes,
  FdoCapabilityType_LockTypes,
  FdoCapabilityType_SupportsLocking,
  FdoCapabilityType_SupportsTimeout,
  FdoCapabilityType_SupportsTransactions,
  FdoCapabilityType_SupportsLongTransactions,
  FdoCapabilityType_SupportsSQL,
  FdoCapabilityType_SupportsConfiguration,
  FdoCapabilityType_SupportsMultipleSpatialContexts,
  FdoCapabilityType_SupportsCSysWKTFromCSysName,
  FdoCapabilityType_SupportsWrite,
  FdoCapabilityType_SupportsMultiUserWrite,
  FdoCapabilityType_SupportsFlush,

  // Expression Capabilities

  FdoCapabilityType_ExpressionTypes,


  // Filter Capabilities

  FdoCapabilityType_ConditionTypes,
  FdoCapabilityType_SpatialOperations,
  FdoCapabilityType_DistanceOperations,
  FdoCapabilityType_SupportsGeodesicDistance,
  FdoCapabilityType_SupportsNonLiteralGeometricOperations,

  // Geometry Capabilities

  FdoCapabilityType_GeometryTypes,
  FdoCapabilityType_GeometryComponentTypes,
  FdoCapabilityType_Dimensionalities,

// Raster Capabilities

  FdoCapabilityType_SupportsRaster,
  FdoCapabilityType_SupportsStitching,
  FdoCapabilityType_SupportsSubsampling,
  FdoCapabilityType_SupportsDataModel,

  // Schema Capabilities

  FdoCapabilityType_ClassTypes,
  FdoCapabilityType_DataTypes,
  FdoCapabilityType_SupportedAutoGeneratedTypes,
  FdoCapabilityType_SupportedIdentityPropertyTypes,
  FdoCapabilityType_MaximumDataValueLength_String,
  FdoCapabilityType_MaximumDataValueLength_BLOB,
  FdoCapabilityType_MaximumDataValueLength_CLOB,
  FdoCapabilityType_MaximumDataValueLength_Decimal,
  FdoCapabilityType_MaximumDataValueLength_Boolean,
  FdoCapabilityType_MaximumDataValueLength_Byte,
  FdoCapabilityType_MaximumDataValueLength_DateTime,
  FdoCapabilityType_MaximumDataValueLength_Double,
  FdoCapabilityType_MaximumDataValueLength_Int16,
  FdoCapabilityType_MaximumDataValueLength_Int32,
  FdoCapabilityType_MaximumDataValueLength_Int64,
  FdoCapabilityType_MaximumDataValueLength_Single,
  FdoCapabilityType_MaximumDecimalPrecision,
  FdoCapabilityType_MaximumDecimalScale,
  FdoCapabilityType_NameSizeLimit_Datastore,
  FdoCapabilityType_NameSizeLimit_Schema,
  FdoCapabilityType_NameSizeLimit_Class,
  FdoCapabilityType_NameSizeLimit_Property,
  FdoCapabilityType_NameSizeLimit_Description,
  FdoCapabilityType_ReservedCharactersForName,
  FdoCapabilityType_SupportsAssociationProperties,
  FdoCapabilityType_SupportsAutoIdGeneration,
  FdoCapabilityType_SupportsCalculatedProperties,
  FdoCapabilityType_SupportsCompositeId,
  FdoCapabilityType_SupportsCompositeUniqueValueConstraints,
  FdoCapabilityType_SupportsDataStoreScopeUniqueIdGeneration,
  FdoCapabilityType_SupportsDefaultValue,
  FdoCapabilityType_SupportsExclusiveValueRangeConstraints,
  FdoCapabilityType_SupportsInclusiveValueRangeConstraints,
  FdoCapabilityType_SupportsInheritance,
  FdoCapabilityType_SupportsMultipleSchemas,
  FdoCapabilityType_SupportsNetworkModel,
  FdoCapabilityType_SupportsNullValueConstraints,
  FdoCapabilityType_SupportsObjectProperties,
  FdoCapabilityType_SupportsSchemaModification,
  FdoCapabilityType_SupportsSchemaOverrides,
  FdoCapabilityType_SupportsUniqueValueConstraints,
  FdoCapabilityType_SupportsValueConstraintsList,
  FdoCapabilityType_SupportsWritableIdentityProperties,

  // Topology Capabilities

  FdoCapabilityType_SupportsTopology,
  FdoCapabilityType_SupportsTopologicalHierarchy,
  FdoCapabilityType_BreaksCurveCrossingsAutomatically,
  FdoCapabilityType_ActivatesTopologyByArea,
  FdoCapabilityType_ConstrainsFeatureMovements,

}  //  enum FdoCapabilityType

The 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):

public __value enum CapabilityType
{
  // Command Capabilities

  CapabilityType_CommandList,
  CapabilityType_SupportsParameters,
  CapabilityType_SupportsTimeout,
  CapabilityType_SupportsSelectExpressions,
  CapabilityType_SupportsSelectFunctions,
  CapabilityType_SupportsSelectDistinct(),
  CapabilityType_SupportsSelectOrdering(),
  CapabilityType_SupportsSelectGrouping(),

  // Connection Capabilities

  CapabilityType_ThreadCapability,
  CapabilityType_SpatialContextTypes,
  CapabilityType_LockTypes,
  CapabilityType_SupportsLocking,
  CapabilityType_SupportsTimeout,
  CapabilityType_SupportsTransactions,
  CapabilityType_SupportsLongTransactions,
  CapabilityType_SupportsSQL,
  CapabilityType_SupportsConfiguration,
  CapabilityType_SupportsMultipleSpatialContexts,
  CapabilityType_SupportsCSysWKTFromCSysName,
  CapabilityType_SupportsWrite,
  CapabilityType_SupportsMultiUserWrite,
  CapabilityType_SupportsFlush,

  // Expression Capabilities

  CapabilityType_ExpressionTypes,


  // Filter Capabilities

  CapabilityType_ConditionTypes,
  CapabilityType_SpatialOperations,
  CapabilityType_DistanceOperations,
  CapabilityType_SupportsGeodesicDistance,
  CapabilityType_SupportsNonLiteralGeometricOperations,

  // Geometry Capabilities

  CapabilityType_GeometryTypes,
  CapabilityType_GeometryComponentTypes,
  CapabilityType_Dimensionalities,

// Raster Capabilities

  CapabilityType_SupportsRaster,
  CapabilityType_SupportsStitching,
  CapabilityType_SupportsSubsampling,
  CapabilityType_SupportsDataModel,

  // Schema Capabilities

  CapabilityType_ClassTypes,
  CapabilityType_DataTypes,
  CapabilityType_SupportedAutoGeneratedTypes,
  CapabilityType_SupportedIdentityPropertyTypes,
  CapabilityType_MaximumDataValueLength_String,
  CapabilityType_MaximumDataValueLength_BLOB,
  CapabilityType_MaximumDataValueLength_CLOB,
  CapabilityType_MaximumDataValueLength_Decimal,
  CapabilityType_MaximumDataValueLength_Boolean,
  CapabilityType_MaximumDataValueLength_Byte,
  CapabilityType_MaximumDataValueLength_DateTime,
  CapabilityType_MaximumDataValueLength_Double,
  CapabilityType_MaximumDataValueLength_Int16,
  CapabilityType_MaximumDataValueLength_Int32,
  CapabilityType_MaximumDataValueLength_Int64,
  CapabilityType_MaximumDataValueLength_Single,
  CapabilityType_MaximumDecimalPrecision,
  CapabilityType_MaximumDecimalScale,
  CapabilityType_NameSizeLimit_Datastore,
  CapabilityType_NameSizeLimit_Schema,
  CapabilityType_NameSizeLimit_Class,
  CapabilityType_NameSizeLimit_Property,
  CapabilityType_NameSizeLimit_Description,
  CapabilityType_ReservedCharactersForName,
  CapabilityType_SupportsAssociationProperties,
  CapabilityType_SupportsAutoIdGeneration,
  CapabilityType_SupportsCalculatedProperties,
  CapabilityType_SupportsCompositeId,
  CapabilityType_SupportsCompositeUniqueValueConstraints,
  CapabilityType_SupportsDataStoreScopeUniqueIdGeneration,
  CapabilityType_SupportsDefaultValue,
  CapabilityType_SupportsExclusiveValueRangeConstraints,
  CapabilityType_SupportsInclusiveValueRangeConstraints,
  CapabilityType_SupportsInheritance,
  CapabilityType_SupportsMultipleGeometries,
  CapabilityType_SupportsMultipleSchemas,
  CapabilityType_SupportsNetworkModel,
  CapabilityType_SupportsNullValueConstraints,
  CapabilityType_SupportsObjectProperties,
  CapabilityType_SupportsSchemaModification,
  CapabilityType_SupportsSchemaOverrides,
  CapabilityType_SupportsUniqueValueConstraints,
  CapabilityType_SupportsValueConstraintsList,
  CapabilityType_SupportsWritableIdentityProperties,

  // Topology Capabilities

  CapabilityType_SupportsTopology,
  CapabilityType_SupportsTopologicalHierarchy,
  CapabilityType_BreaksCurveCrossingsAutomatically,
  CapabilityType_ActivatesTopologyByArea,
  CapabilityType_ConstrainsFeatureMovements,

}  //  CapabilityType

Like the command enumeration, the capability enumeration can be extended by the providers to add their own capabilities if this is required.

Data Store Level Capability Support

To 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:

FDO_API virtual FdoICommandCapabilities    *GetCommandCapabilities    (bool datastoreLevel = false) = 0;
FDO_API virtual FdoIConnectionCapabilities *GetConnectionCapabilities (bool datastoreLevel = false) = 0;
FDO_API virtual FdoIExpressionCapabilities *GetExpressionCapabilities (bool datastoreLevel = false) = 0;
FDO_API virtual FdoIFilterCapabilities     *GetFilterCapabilities     (bool datastoreLevel = false) = 0;
FDO_API virtual FdoIGeometryCapabilities   *GetGeometryCapabilities   (bool datastoreLevel = false) = 0;
FDO_API virtual FdoIRasterCapabilities     *GetRasterCapabilities     (bool datastoreLevel = false) = 0;
FDO_API virtual FdoISchemaCapabilities     *GetSchemaCapabilities     (bool datastoreLevel = false) = 0;
FDO_API virtual FdoITopologyCapabilities   *GetTopologyCapabilities   (bool datastoreLevel = false) = 0;
FDO_API virtual FdoICapability             *GetCapability             (bool datastoreLevel = false) = 0;

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

The 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:

NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICommandCapabilities    *GetCommandCapabilities    (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IConnectionCapabilities *GetConnectionCapabilities (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IExpressionCapabilities *GetExpressionCapabilities (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IFilterCapabilities     *GetFilterCapabilities     (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IGeometryCapabilities   *GetGeometryCapabilities   (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::IRasterCapabilities     *GetRasterCapabilities     (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ISchemaCapabilities     *GetSchemaCapabilities     (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ITopologyCapabilities   *GetTopologyCapabilities   (System::Boolean datastoreLevel);
NAMESPACE_OSGEO_FDO_CONNECTIONS_CAPABILITIES::ICapability             *GetCapability             (System::Boolean datastoreLevel);

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

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

Eliminate Provider Specific Processing in Applications

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

Arc Support

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

The 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:

bool SupportsArcSegmentStorage (FdoString *wktCoordinateSystemName);

Calculated Property Support

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

The new capability will be addressed with the new capability interface. The capability identifier will be !CapabilityType_SupportsCalculatedProperties.

Writable Identity Property Support

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

Multiple Geometry Support

There are two parts to this item:

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

Optimization

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

Investigation 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:

Filter:

  a = 1 or a = 2 or a = 3 or a = 4

Generated SQL statement:

  ((((a = 1) or (a = 2)) or (a = 3)) or (a = 4))

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

The 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:

Filter:

  a = 1 or a = 2 or a = 3 or a = 4

Generated SQL statement:

  (a = 1) or (a = 2) or (a = 3) or (a = 4)

Once the nesting is eliminated the originally reported issue no longer appears. As a result there is no need for additional capabilities.

Test Plan

Existing unit tests will be enhanced and new unit tests added to test all changes.

Funding/Resources

Autodesk to provide resource / funding to implement the feature for the affected providers.

Note: See TracWiki for help on using the wiki.

Download in other formats:

Plain Text