FDO 3.0 vs. FDO 3.2

FDO API Naming Changes

The naming conventions used in version 3.2 of the FDO API have been modified from those exposed in version 3.0. These modifications were undertaken to move the naming conventions used in the API away from its Autodesk roots and position itself within the OSGeo framework. As a result of implementing these changes, users will be required to modify their applications to use the names of the renamed FDO classes, enumerations,  header files, libraries, etc.

 

NOTE: The API changes made moving from 3.0 and 3.2 are also applicable when discussing the differences between 3.1 and 3.2.

 

The following sections provide an overview on the naming changes that were made in FDO 3.2.

Removal of Unused FDO API Interfaces

There was a subset of the FDO API that had not been implemented in any provider. These unimplemented interfaces were removed from the FDO API.

Removal of the Topology API

Removing the Topology API meant that all the topology related classes, files and enumeration values were removed from the FDO API.

 

A summary of the required changes are as follows:

 

·        The FdoITopologyCapabilities interface was removed from the FDO API.

 

·        The FdoIConnection interface was modified to remove the topology related capabilities method.

 

virtual FdoITopologyCapabilities* GetTopologyCapabilities();

 

·        The FdoCommandType Enumeration was updated to remove the Topology related enumeration values.

 

FdoCommandType_ActivateTopologyArea

FdoCommandType_DeactivateTopologyArea

FdoCommandType_ActivateTopologyInCommandResult

FdoCommandType_DeactivateTopologyInCommandResults

 

·        The following command interfaces were removed from the FDO API as well as their associated .h and .cpp files.

 

FdoIActivateTopologyArea

FdoIDeactivateTopologyArea

FdoIActivateTopologyInCommandResults

FdoIDeactivateTopologyInCommandResults

FdoIMoveTopoNode

FdoIReconnectTopoEdge

 

·        The following schema management classes were removed from the FDO API as well as their associated .h and .cpp files.

 

FdoTopoGeometryPropertyDefinition

FdoTopology

 

Removal of the Network API

Removing the Network API will mean that all the network related classes, files and enumeration values were removed from the FDO API.

 

A summary of the required changes are as follows:

 

·        The FdoISchemaCapabilities interface was modified to remove the following network related capabilities method.

 

virtual bool SupportsNetworkModel();

 

·        The FdoCommandType Enumeration was updated to remove the FDO Network related enumeration values.

 

FdoCommandType_NetworkShortestPath

FdoCommandType_NetworkAllPaths

FdoCommandType_NetworkReachableNodes

FdoCommandType_NetworkReachingNodes

FdoCommandType_NetworkNearestNeighbors

FdoCommandType_NetworkWithinCost

FdoCommandType_NetworkTSP

 

·        The following command and reader interfaces were removed from the FDO API as well as their associated .h and .cpp files.

 

FdoINetworkCommand

FdoINetworkAllPathsCommand

FdoINetworkNearestNeighborsCommand

FdoINetworkPathReader

FdoINetworkReachableNodesCommand

FdoINetworkReachingNodesCommand

FdoINetworkReader

FdoINetworkShortestPathCommand

FdoINetworkTSPCommand

FdoINetworkWithinCostCommand

 

·        The following enumeration values were removed from the FdoClassType enumeration.

 

FdoClassType_NetworkClass,

FdoClassType_NetworkLayerClass,

FdoClassType_NetworkNodeClass,

FdoClassType_NetworkLinkClass

 

·        The following schema management classes were removed from the API as well as their associated .h and .cpp files.

 

FdoNetworkClass

FdoNetworkFeatureClass

FdoNetworkLayerClass

FdoNetworkLinkFeatureClass

FdoNetworkNodeFeatureClass

Naming Modifications for the FDO API Libraries

Components in the FDO API were renamed to remove references to Gis and to standardize the components to use FDO (uppercase) as a prefix. 

 

Component

Description

GisCommon

Common type definition and templates. Renamed to FDOCommon.

GisGeometry

Geometry interfaces and factory for FGF. Renamed to FDOGeometry

FdoMessage

Message catalogue for FDO. Renamed to FDOMessage

GisMessage

Message catalogue for GisCommon and GisGeometry Integrated with FDOMessage to form a single message catalogue.

GisNLS

Globalization utility Renamed to FDONLS

GisSpatial

Utility component around GisGeometry.  Includes: geometry validation, transformation of ordinate (integer to double), approximation algorithm. Renamed to FDOSpatial

MgCommon

Managed wrapper for GisCommon. Renamed to OSGeo.FDO.Common.dll

MgFDO

Managed wrapper for Fdo.  Renamed to OSGeo.FDO.dll

MgGeometry

Managed wrapper for GisGeometry. Renamed to OSGeo.FDO.Geometry.dll

MgSpatial

Spatial utility based on GisGeometry. Renamed to OSGeo.FDO.Spatial.dll

 

 

Enforcing Open Source Code Naming Conventions

With these changes, all class names in the FDO API should now start with camel case “Fdo”. The FDO interface definitions will start with “FdoI”. Class members will be defined by getter and setter prefix with Get/Set. 

 

The FDO providers implmentations have been 'somewhat' standardized to name their Fdo implementation classes following the pattern: Fdo<provider abbreviation>Implementation.

 

The current FDO API makes use of terms ‘Autodesk’ and ‘Gis’. These terms will be replaced in the Open Source release with ‘OSGeo’ and ‘Fdo’. The following sections outline the major areas of change.

Managed API Namespaces Changes

In version 3.0 the namespaces for the FDO Managed APIs refer to Autodesk.Gis.Fdo.  These namespaces will be modified to reference OSGeo.FDO as follows:

 

3.0 API

3.2 API

Autodesk.Gis

OSGeo

Autodesk.Gis.Runtime

OSGeo.Runtime

Autodesk.Gis.Common

OSGeo.Common

Autodesk.Gis.Geometry

OSGeo.Geometry

Autodesk.Gis.Spatial

OSGeo.Spatial

Autodesk.Gis.Fdo

OSGeo.FDO

Autodesk.Gis.Fdo.Utilities

OSGeo.FDO.Utilities

Autodesk.Gis.Fdo.Providers

OSGeo.FDO.Providers

Autodesk.Gis.Fdo.Providers.Shape

OSGeo.FDO.Providers.SHP

Autodesk.Gis.Fdo.Providers.ODBC

OSGeo.FDO.Providers.ODBC

Autodesk.Gis.Fdo.Providers.MySQL

OSGeo.FDO.Providers.MySQL

Autodesk.Gis.Fdo.Providers.WMS

OSGeo.FDO.Providers.WMS

Autodesk.Gis.Fdo.Providers.WFS

OSGeo.FDO.Providers.WFS

Macro/Preprocessor Name Changes

There are a number of FDO macro and preprocessor definitions that were renamed to remove references to Gis.

 

3.0 API

3.2 API

EXP_GIS

EXP_FDO

EXP_GISGEOM

EXP_GEOM

GIS_API

FDO_API

GISGEOM_API

GEOM_API

GISSPATIAL_STATIC

SPATIAL_STATIC

EXP_GISSPATIAL

EXP_SPATIAL

GISSPATIAL_API

SPATIAL_API

GIS_COLL_MAP_THRESHOLD

FDO_COLL_MAP_THRESHOLD

GIS_NLSID

FDO_NLSID

GIS_SAFE_RELEASE

FDO_SAFE_RELEASE

GIS_SAFE_ADDREF

FDO_SAFE_ADDREF

Type Name Changes

There were a number of FDO type definitions that were renamed to remove references to Gis.

 

3.0 API

3.2 API

GisDimensionality

FdoDimensionality

GisGeometryType

FdoGeometryType

GisGeometryComponentType

FdoGeometryComponentType

GisStreamReaderType

FdoStreamReaderType

GisSpatialGeometryValidity

FdoSpatialGeometryValidity

GisToken

FdoToken

gis_awkt_yytokentype

fdo_awkt_yytokentype

GisByte

FdoByte

GisInt8

FdoInt8

GisInt16

FdoInt16

GisInt32

FdoInt32

GisInt64

FdoInt64

GisCharacter

FdoCharacter

GisVoid

FdoVoid

GisDouble

FdoDouble

GisFloat

FdoFloat

GisSize

FdoSize

GisBoolean

FdoBoolean

GisString

FdoString

GisDateTime

FdoDateTime

GisSpatialGeometryValidity

FdoSpatialGeometryValidity

Class/Interface Name Changes

The prefix for the FDO Common classes was changed from Gis to Fdo

 

3.0 Class Names

3.2 Class Names

 

 

GisArray

FdoArray

GisIntArray

FdoIntArray

GisArrayHelper

FdoArrayHelper

GisCollection

FdoCollection

GisDictionary

FdoDictionary

GisDictionaryElement

FdoDictionaryElement

GisDisposable

FdoDisposable

GisIDisposable

FdoIDisposable

GisException

FdoException

GisPtr

FdoPtr

GisSemaphore

FdoSemaphore

GisStringP

FdoStringP

GisIDisposable

FdoIDisposable

GisIStreamReader

FdoIStreamReader

GisIStreamReaderTmpl

FdoIStreamReaderTmpl

GisNamedCollection

FdoNamedCollection

GisReadOnlyNamedCollection

FdoReadOnlyNamedCollection

GisRestrictedNamedCollection

FdoRestrictedNamedCollection

GisStack

FdoStack

GisStringElement

FdoStringElement

GisStringCollection

FdoStringCollection

GisStringsP

FdoStringsP

GisDateTime

FdoDateTime

GisVectorElement

FdoVectorElement

GisVector

FdoVector

GisVectorP

FdoVectorP

GisGml212

FdoGml212

GisGml212Schema

FdoGml212Schema

GisIoBufferStream

FdoIoBufferStream

GisIoByteStreamReader

FdoIoByteStreamReader

GisIoFileStream

FdoIoFileStream

GisIoMemoryStream

FdoIoMemoryStream

GisIoObjectStreamReader

FdoIoObjectStreamReader

GisIoObjectStream

FdoIoObjectStream

GisIoStream

FdoIoStream

GisIoTextReader

FdoIoTextReader

GisIoTextWriter

FdoIoTextWriter

GisXmlAttribute

FdoXmlAttribute

GisXmlAttributeCollection

FdoXmlAttributeCollection

GisXmlCharDataHandler

FdoXmlCharDataHandler

GisXmlCopyHandler

FdoXmlCopyHandler

GisXmlReader

FdoXmlReader

GisXmlSaxContext

FdoXmlSaxContext

GisXmlSaxHandler

FdoXmlSaxHandler

GisXmlSkipElementHandler

FdoXmlSkipElementHandler

GisXmlUtilXrcs

FdoXmlUtilXrcs

GisXmlWriter

FdoXmlWriter

GisXml

FdoXml

GisXslTransformer

FdoXslTransformer

GisXslTransformerXalan

FdoXslTransformerXalan

 

 

 

NOTE: Class GisException and class FdoException were merged together to form a single FdoException exception class.

 

The prefix of the FDO Geometry classes was changed from Gis to Fdo

 

3.0 Class Names

3.2 Class Names

 

 

GisDirectPositionImpl

FdoDirectPositionImpl

GisEnvelopeImpl

FdoEnvelopeImpl

GisGeometryFactoryAbstract

FdoGeometryFactoryAbstract

GisIArcSegmentAbstract

FdoIArcSegmentAbstract

GisICircularArcSegment

FdoICircularArcSegment

GisICurveAbstract

FdoICurveAbstract

GisICurvePolygon

FdoICurvePolygon

GisCurvePolygonCollection

FdoCurvePolygonCollection

GisICurveSegmentAbstract

FdoICurveSegmentAbstract

GisCurveSegmentCollection

FdoCurveSegmentCollection

GisICurveString

FdoICurveString

GisCurveStringCollection

FdoCurveStringCollection

GisIDirectPosition

FdoIDirectPosition

GisDirectPositionCollection

FdoDirectPositionCollection

GisIEnvelope

FdoIEnvelope

GisIGeometricAggregateAbstract

FdoIGeometricAggregateAbstract

GisIGeometry

FdoIGeometry

GisGeometryCollection

FdoGeometryCollection

GisILinearRing

FdoILinearRing

GisLinearRingCollection

FdoLinearRingCollection

GisILineString

FdoILineString

GisLineStringCollection

FdoLineStringCollection

GisILineStringSegment

FdoILineStringSegment

GisIMultiCurvePolygon

FdoIMultiCurvePolygon

GisIMultiCurveString

FdoIMultiCurveString

GisIMultiGeometry

FdoIMultiGeometry

GisIMultiLineString

FdoIMultiLineString

GisIMultiPoint

FdoIMultiPoint

GisIMultiPolygon

FdoIMultiPolygon

GisIPoint

FdoIPoint

GisPointCollection

FdoPointCollection

GisIPolygon

FdoIPolygon

GisPolygonCollection

FdoPolygonCollection

GisIRing

FdoIRing

GisRingCollection

FdoRingCollection

GisIRingAbstract

FdoIRingAbstract

GisISurfaceAbstract

FdoISurfaceAbstract

GisAgfGeometryFactory

FdoFgfGeometryFactory

GisGeometryStreamFactory

FdoGeometryStreamFactory

GisGeometryStreamReader

FdoGeometryStreamReader

GisGeometryStreamWriter

FdoGeometryStreamWriter

 

 

 

The prefix of the FDO Spatial API classes was changed from Gis to Fdo

 

3.0 Class Name

3.2 Class Name

 

 

GisSpatialGridTransform

FdoSpatialGridTransform

GisSpatialUtility

FdoSpatialUtility

 

 

AGF to FGF Name Change

The FDO API used the term AGF or Autodesk Geometry Format in version 3.0 of it’s API. In version 3.2 This term will be replaced with FGF which shall represent Fdo Geometry Format or Feature Geometry Format.

 

In order to make this change the geometry class that handles the creation of AGF geometry GisAgfGeometryFactory and GisAgfGeometryFactory2, will have to be renamed FdoFgfGeometryFactory and FdoFgfGeometryFactory2. There are also factory methods such as CreateGeometryFromAgf and GetAgf that will need to be modified.

 

3.0 Factory Method Name

3.2 Factory Method Name

 

 

CreateGeometryFromAgf

CreateGeometryFromFgf

GetAgf

GetFgf

 

 

SHP Override API Class Naming Conventions

Physical Overrides APIs are defined for the SHP, ODBC, MySQL and WMS providers. In 3.0, the naming conventions for the APIs had not been standardized. As a part of the Open Source preparedness effort, these APIs were standardized to use a common prefix of Fdo[Provider]Ov. This naming convention is already in use for the ODBC, MySQL and WMS providers. The SHP provider will be updated to also follow this standard. The following table outlines the Open Source class names that are bow used for the 3.2 version of the FDO SHP Provider.

 

3.0 Class Name

3.2 Class Name

 

 

FdoShpClassCollection

FdoShpOvClassCollection

FdoShpClassDefinition

FdoShpOvClassDefinition

FdoShpColumnDefinition

FdoShpOvColumnDefinition

FdoShpPhysicalSchemaMapping

FdoShpOvPhysicalSchemaMapping

FdoShpPropertyDefinition

FdoShpOvPropertyDefinition

FdoShpPropertyDefinitionCollection

FdoShpOvPropertyDefinitionCollection

 

 

File Name Changes

Several FDO API files have had their names changes to conform to the common file naming convention or to remove GIS from their filenames.

 

3.0 File Name

3.2 File Name

GisCommon.h

FdoCommon.h

GisGeometry.h

FdoGeometry.h

GisMessage.h

FdoMessage.h

common/Types.h

Common/FdoTypes.h

common/GisPtr.h

Common/Ptr.h

common/GisSemaphore.h

Common/Semaphore.h

common/GisStd.h

Common/Std.h

common/GisStringp.h

Common/Stringp.h

fdo/FdoCollection.h

Common/Collection.h

fdo/FdoException.h

Common/Exception.h

Geometry/AgfGeometry/AgfGeometryFactory.h

Geometry/Fgf/Factory.h

Spatial/GisSpatialGeometryValidity.h

Spatial/SpatialGeometryValidity.h

Spatial/GisSpatialGridTransform.h

Spatial/SpatialGridTransform.h

Spatial/GisSpatialStd.h

Spatial/SpatialStd.h

Spatial/GisSpatialUtility.h

Spatial/SpatialUtility.h

 

 

Documentation

In Version 3.2, the FDO Open Source API reference documentation will be generated using Doxygen. API documentation content will retrieved directly from the header files that constitute the public FDO API.

Capabilities Related Changes

In FDO 3.2, additional capabilities support was added to the FDO API for the following use cases.

 

·        Identify if the provider supports write.

·        Identify size limits of various schema elements such as maximum name sizes and string sizes.

·        Identify the characters that are not valid for schema element names.

·        Support specifying explicit geometry types allowed for a geometry property.

Connection Capabilities

The main addition is to indicate whether the data store is read-only or can support write. By adding a SupportsWrite() capability, the client can find out if the provider is read-only. Note that this is related to being able to update data and does not include schema modifications. There is an existing separate schema capability for supporting schema modification.

 

A related addition is a capability indicating if the provider supports multi-user update, i.e. for a provider that supports write, whether more than one user can update the data store at the same time. For example, a file-based data store may be updatable, but only one user at a time whereas a database can support multiple update users at one time.

 

To support the above objectives, two additional capabilities were added to FdoIConnectionCapabilities, with the following methods:

 

// Returns true if write is supported by the provider

virtual FDO_API bool SupportsWrite()=0                

 

// Returns true if the provider can support more than one user writing to a single data store at one time

virtual FDO_API bool SupportsMultiUserWrite=0

 

If write is not supported, then locking, transactions, and multi-user write would also not be supported. If multi-user write is supported then write is supported.

Expression Capabilities

Changes were made for Expression capabilities in order to deal with definitions of overloaded functions. An additional change was to add a flag to identify aggregate functions from simple functions. E.g. Max() is an aggregate functions that computes a single result from a set of objects whereas Sqrt() is a simple function that operates on a single value.

 

To be able to support overloaded functions, we need a way to describe a set of function signatures.

 

E.g.

 

Int32 Max(Int32)

Double Max(Double)

String Max(String)

Date Max(Date)

 

The enhancements define a signature structure and a signature collection structure which can be returned from a function definition.

 

In order to support the above concepts, a new class FdoSignatureDefinition was added to the FDO API with the following methods:

 

// Gets an array of FdoArgumentDefinition objects required for the function.

FDO_API FdoReadOnlyArgumentDefinitionCollection * GetArguments () 

 

// Gets the FdoPropertyType of the function return value

FDO_API FdoPropertyType GetReturnPropertyType ()

 

// Gets the FdoDataType of the function return value. This is only valid if the function return property type is FdoPropertyType_DataProperty

FDO_API FdoDataType GetReturnType()

 

In order to collect instances of FdoSignatureDefinition into a collection, a read-only collection FdoReadOnlySignatureDefinitionCollection was also added to the FDO API:

 

Finally, to FdoFunctionDefinition, the following methods were added:

 

// Gets an array of FdoSignatureDefinition objects that describe the different signatures supported by the function

FDO_API FdoReadOnlySignatureDefinitionCollection * GetSignatures ()

 

// Returns true if the function is an aggregate function and false if it is a simple function.

FDO_API bool IsAggregate()

 

For backwards compatibility, for the overloaded functions, the existing methods GetArguments() and GetReturnType() would return the same result as they do now. For the currently supported aggregate functions of min(), max(), avg(), ceil(), floor(), etc., the capabilities currently show that they take a double value argument and return a double value.

Schema Capabilities and Schema Limits

Additions were made to the FDO API Schema capabilities in order to be able to describe limits on name sizes and maximum value sizes.

 

The following are the additional limit information added to this set of capabilities.

 

·        Maximum data store name size.

·        Maximum schema name size.

·        Maximum class name size.

·        Maximum property name size.

·        Maximum size of description.

·        List of reserved characters for: data store name, schema name, class name, and property name.

 

A list of reserved characters rather than a list of valid characters was chosen because in the general case, a list of valid characters would be very long and difficult to determine a complete list when the various supported national languages are taken into account. The list of reserved characters is usually relatively small and easier to determine for sources such as Oracle, SQL Server, etc. This list is a list of wide-char characters.

 

There are two additional schema capabilities that are added.

 

·        Supported properties that can be used for identity properties.

·        Supports default value specification for a property.

 

Here is the enumerator for the name types.

 

enum FdoSchemaElementNameType:

 

FdoSchemaElementNameType_Datastore

Data store name

FdoSchemaElementNameType_Schema

Schema name

FdoSchemaElementNameType_Class

Class name

FdoSchemaElementNameType_Property

Property name

FdoSchemaElementNameType_Description

Description field

 

To FdoISchemaCapabilities add the following new functions:

 

// Returns the maximum size of a value of the given type. It includes class name size limits, property name size limits, description size limits, etc.

virtual FDO_API FdoInt32 GetNameSizeLimit (FdoSchemaElementNameType name)=0

 

// This returns a string that includes all the reserved characters that cannot be used for the various schema element names (e.g. data store name, class name, etc.) for the provider

virtual FDO_API FdoString * GetReservedCharactersForNames()=0

 

// Returns TRUE if default values can be specified for a data property definition and FALSE otherwise

virtual FDO_API FdoDataType * SupportsDefaultValue ()=0

 

// Gets a list of the property types that can be used for identity properties

virtual FDO_API FdoDataType * GetSupportedIdentityPropertyTypes (FdoInt32 &length)=0

 

There are also limits that apply to data properties that need to be exposed through the API

 

·        Maximum precision for Decimal.

·        Maximum scale for Decimal.

·        Maximum length for String.

·        Maximum length for BLOB.

·        Maximum length for CLOB.

 

In order to support these limits, the following functions were added to FdoISchemaCapabilities.

 

// Gets the maximum supported length of String, BLOB, or CLOB data properties. For decimal,

// it would be the max scale plus max precision. For other data types that are not variable in size,

// the value returned is the byte length. Note that this returns int64 because some providers

// support blob lengths that won’t fit into int32

virtual FDO_API FdoInt64 GetMaximumDataValueLength (FdoDataType dataType)=0

 

// Gets the maximum supported precision for the Decimal data property.

virtual FDO_API FdoInt32 GetMaximumDecimalPrecision()=0

 

// Gets the maximum supported scale for the Decimal data property.

virtual FDO_API FdoInt32 GetMaximumDecimalScale()=0

 

Geometry Types for Geometry Property

For Geometry properties, the FDO API needed the ability to specify the specific geometry types that the property will support. Currently, even though the methods are called Set/Get GeometryTypes(), the settings are “geometric” types indicating point, linear, or area. These are not specific since linear can include polyline, multi-polyline, multi-curve, etc. Point can include either point or multi-point. For many cases, users need to specify a specific one or set of geometry types or determine the specify type that is allowed. E.g. for SHP data stores, the geometry has to be one specific type. If it’s point, then only point is allowed and not multi-point.

 

Unfortunately, the current methods use the name GeometryTypes, which would have been the obvious choice for a new set of methods. SpecificGeometryTypes was chosen instead. Therefore, the following FdoGeometricPropertyDefinition methods were added to the API.

 

// Gets the specific Geometry types that can be stored in this geometric property.

// The returned value is a list of the geometry types that are supported, with length

// being the number of types returned.

FDO_API FdoGeometryType* GetSpecificGeometryTypes (FdoInt32& length)

 

// Sets the specific set of Geometry types that can be stored in this geometric property.

// The value is a list of geometry types.  Usually, one specific type is supported,

// but there can be more than one.

FDO_API FdoGeometryType* SetSpecificGeometryTypes (FdoGeometryType* types, FdoInt32 length)

Interaction with existing methods

 

If SetGeometryTypes() is used and then GetSpecificGeometryTypes() is called, the new method will return the complete list of geometry types that the geometric type allows. E.g. if the geometric type is FdoGeometricType_Point, then FdoGeometryType_Point and FdoGeometryType_MultiPoint will be returned from GetSpecificGeometryTypes(). For the other way around, if SetSpecificGeometryTypes() is called followed by GetGeometryTypes(), it will only return geometric types if all the related geometry types have been specified. E.g. it would show FdoGeometricType_Point only if both FdoGeometryType_Point and FdoGeometryType_MultiPoint are set. It is possible if no geometric type is completely specified that GetGeometryTypes will return 0.

 

Mappings from geometric types to geometry types

 

·        Point: Point, MultiPoint.

·        Linear: Linestring, MultiLineString, CurveString, MultiCurveString.

·        Area: Polygon, MultiPolygon, CurvePolygon, MultiCurvePolygon.

·        Solid: No geometry types exist for the solid geometric type.

·        Point+Linear+Area: All of the above plus MultiGeometry.

 

Due to provider capabilities, the effective list of geometry types for a geometric type for a particular provider may be a subset of the above.

Class Level Capabilities

Add the following method to the FdoClassCapabilities Interface

 

// Returns true if the class supports write

FDO_API FdoBoolean SupportsWrite()=0

 

Data Store Type and Dependent Files

This enhancement is to provide a way for an FDO user to find out whether a provider is a file-based provider, database-based provider, or web server type of provider (e.g. WFS). Further, for file-based providers, it will provide a list of the dependent files for the data store. E.g. a SHP file contains a set of related files, .shp, .prj, .dbf, etc.

 

While most providers are of a single type, e.g. SDF provider is always a file provider, and Oracle is always a database provider, some providers such as ODBC and OGR would vary depending on the specific connection.

 

There will be cases with ODBC and presumably OGR and FME providers where it will be difficult for the provider to determine the exact data store type due to an extra access layer between the provider and the data. A connection to ODBC is via DSN or ODBC driver specific connection string. If a DSN we would have to try to get the relevant file vs. server information from the ODBC Driver Manager. This may not be straight-forward. This will need to be analyzed. If a connection string we will have to parse the string to find a DSN or determine if a file is specified. This also may be difficult to do especially since the connection string keywords maybe somewhat driver specific.

 

As a result, we may have situations where the ODBC provider will not know if a local file is used or if a server is used. For these cases, the provider will return an “unknown” data store type.

 

This enhancement adds the following methods to the FdoIConnectionInfo interface.

 

// Returns the data store type supported by the current connection of the provider

FDO_API FdoProviderDatastoreType GetProviderDatastoreType()=0

 

// Get a list of the dependent files for the current connection for file-based data stores.

// File names include full path qualification.

FDO_API FdoStringCollection* GetDependentFileNames()=0

 

Add an FdoProviderDatastoreType enumerator:

 

enum FdoProviderDatastoreType:

 

FdoProviderDatastoreType_Unknown

Unknown type.

FdoProviderDatastoreType_File

File-base data store.

FdoProviderDatastoreType_DatabaseServer

DBMS data store.

FdoProviderDatastoreType_WebServer

Web server.

 

Some providers support a connection to a file directory, e.g. SHP provider. In this case, the list of dependent files would include all the relevant files in the directory that are used for that data store. If the directory contains additional files that don’t make up the data store, e.g. .doc files, they are not included in the list. If there is a configuration file in the directory for the SHP data store, it is included in the list.

 

The file names returned will include full path qualification.

 

Requesting the list of dependent files for a non-file type provider will result in a null pointer returned.

 

The list of dependent files would only be available once the connection is opened.

 

The current FDO providers fall into the following types:

 

  • File: Raster, SDF, SHP, ODBC*, OGR*
  • DatabaseServer: ArcSDE, MySQL, ODBC*, OGR*
  • WebServer: WFS, WMS

 

* - These could be either file or database server depending on the specific connection.