Changes between Version 16 and Version 17 of FDORfc20

Timestamp:

Jun 11, 2008, 11:53:13 AM (16 years ago)

Author:

thomasknoell

Comment:

--

FDORfc20

@@ -23 +23 @@
 == Motivation ==
 
-The objective of this RFC is to propose enhancements to the capability interfaces of the FDO API in order that applications are able to eliminate all special case handling of FDO provider capabilities. It will be necessary to gather feedback from applications such as OSGeo !MapGuide !OpenSource and Autodesk Map 3D to determine that we have a complete set of capabilities implemented in the FDO API and that all special casing can be eliminated with the proposed changes outlined in this RFC. 
+This RFC addresses the following objectives:
 
-It is also necessary to introduce a previously discussed concept of !DataStore level capabilities. !DataStore capabilities are a necessity in the FDO API due to the fact that certain providers can only communicate certain capabilities that are !DataStore specific after a fully formed connection to the provider has been established. There are cases where a provider may support a certain capability, e.g. write or long transactions, whereas a particular !DataStore for the current connection has limitations. E.g. it may be read only, or it may not support long transactions. Currently, there is no way for a client application to determine these !DataStore specific restrictions except for a few specific cases around class level capabilities. 
+'''''Propose enhancements to the FDO capability interfaces enabling applications to eliminate current provider specific handling'''''
 
-Finally to simplify capability handling as the FDO API evolves, we will evaluate the possibilities of introducing an API change 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. 
+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:
 
-== Scenarios ==
+    * 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.
 
-Here are some areas where the current level of !DataStore agnostic capabilities are insufficient.
+In any case, the addition of a new capability can eliminate the provider specific handling currently implemented.
 
-    * The ODBC provider can connect to different sources from Excel files to Access databases to various RDBMS’. However, the capabilities of each source are somewhat different.
-    * The Oracle provider can connect to different Oracle versions. With the introduction of Oracle XE there is the case of an Oracle datastore that does not support long transaction versioning or persistent locking.
-    * Some providers restrict the type of geometry in a geometry property to a specific type rather than category of types. SHP is a good example of this. The provider may advertise that the geometry can be linear, which implies polyline, multi-polyline, etc. However, when the user enters a multi-polyline geometry, an exception is thrown that it cannot be written. A more fine grained specification of allowed geometry types will avoid these situations.
+
+'''''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 ==