Changes between Version 3 and Version 4 of FDORfc35

Timestamp:

06/08/09 13:18:08 (16 years ago)

Author:

danstoica

Comment:

--

FDORfc35

@@ -13 +13 @@
 ||RFC Status||draft|| 
 ||Implementation Status||draft||
-||Proposed Milestone||3.4.0.0||
+||Proposed Milestone||3.5.0.0||
 ||Assigned PSC guide(s)||Greg Boone||
 ||'''Voting History'''|| ||
@@ -23 +23 @@
 == Overview ==
 
-This RFC is for changing the behavior of GetCapabilitiesX().
+This RFC is for changing the behavior of FdoIConnection::GetXCapabilities().
 
 == Motivation ==
 
-There are cases where a provider indicates support of a capability that is actually not supported by a data store the provider may connect to. For example, if an Oracle data store is not prepared for locking, this functionality is not supported in that data store although the provider itself is capable of providing the functionality. ODBC also can connect to a variety of sources, each with varying levels of capability.
+There are cases where a provider indicates support of a capability that is actually not supported by a data store the provider may connect to. For example, if an Oracle data store is not prepared for locking, this functionality is not supported in that data store although the provider itself is capable of providing the functionality. ODBC also can connect to a variety of sources, each with varying levels of capability. Or there are cases where a user connected to a data store may not have the permission to write. This may be because the data store has a read-only flag (SHP, SDF) or a user has not been granted permissions to write to a data store (RDBMS). In this case, the information the provider level capability SupportsWrite returns is incorrect. 
 
 == Proposed Solution ==
 
-Change the behavior of GetCapabilities.  On an open connection it will retrieve the exact capabilities, specific for that database. 
-On a closed connection the current behavior will be preserved and provider level capaabilities will be returned to the caller.
+Change the behavior of GetXCapabilities(). On an open connection it will retrieve the exact capabilities, specific for that database. 
+On a closed connection the current behavior will be preserved and provider level capabilities will be returned.
+
+Another solution was considered. It consisists in adding a flag on each GetXCapabilities() method, like:
+{{{
+FDO_API virtual FdoIConnectCapabilities *GetConnectionCapabilities(bool dataStoreLevel = false) = 0;
+}}}
+
+This alternative suggests that might be cases when a less accurate response is preferred over the exact one. Therefore it is unlikely 2 signatures are needed.
+
 
 == Implications ==
+
+Several cases have been identified so far as good candidates for improvements: 
+
+SQLite, SDF, SHP: fix SupportsWrite() capability for the case of read-only files.
+MySQL: depends on the storage driver; fix GetCommands() to indicate apply schema is only supported if FDO metadata.
+ODBC: we officially support 6-7 data sources and we need to check all the capabilities.
+Oracle: Oracle express does not support long transaction. Fix GetCommands() so it doesn't return long transaction related commands.
 
 
 == Test Plan ==
 
+Existing provider units tests to be enhanched to exercise the changes.
 
 == Funding/Resources ==