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

DataStore Capability Support

Unmanaged

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.

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.

Managed

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.

The table below specifies the changes to the above functions.

New FdoIConnection/IConnection Functions

Unmanaged

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

Managed

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);

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.

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.

Some capabilities such as thread capability would not be different between provider level and datastore level.

Impact of DataStore Level Capabilities on the Above Capability Sets

Command Capabilities

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

Connection Capabilities

• Of the connection capabilities, locking and long transactions are ones that typically could be different.

Expression Capabilities

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

Filter Capabilities

• As with expressions, these typically would not change, although there could be cases where spatial filters could be more limited.

Geometry Capabilities

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

Raster Capabilities

• Different sources could support different data models.

Schema Capabilities

• At the datastore level, different sources could have different limitations, e.g. different versions of Oracle server or SQL Server, or different ODBC sources.

Issues

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.

Test Plan

Existing unit tests will be enhanced to test all changes.

Funding/Resources

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