FDO RFC 35 - Support Data Store level FDO capabilities
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 | June 08, 2009 |
Last Modified | Dan StoicaTimestamp |
Author | Dan Stoica, Orest Halustchak |
RFC Status | draft |
Implementation Status | draft |
Proposed Milestone | 3.5.0.0 |
Assigned PSC guide(s) | Greg Boone |
Voting History | |
+1 | |
+0 | |
-0 | |
-1 |
Overview
This RFC is for changing the behavior of existing FdoIConnection::GetXCapabilities() methods.
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. Examples:
- 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 can connect to a variety of sources, each with varying levels of capability.
- 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 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.
Note another solution has been considered. It consists 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 accurate one. Therefore it is unlikely this flexibility is ever 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 transactions. Fix GetCommands() so it doesn't return long transaction related commands.
Test Plan
Existing providers unit tests to be enhanced to exercise the changes.
Funding/Resources
Autodesk to provide resources / funding.