Changes between Version 27 and Version 28 of FDORfc50

Timestamp:

06/04/10 06:43:44 (14 years ago)

Author:

gregboone

Comment:

--

FDORfc50

@@ -39 +39 @@
         * '''Cons''': We add a new command and a new type command, we already have a FdoIExtendedSelect for scrollable readers and users can be confused by those two commands. This will add more complexity in the API.
 
-    * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()''. Create an !FdoSelect base class and add default implementers for these methods. Then each provider would be changed to base their select command implementations on !FdoSelect instead of FdoISelect. To allow the join functionality to be fully integrated, two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilites would be named: !SupportsJoins() & !GetJoinTypes(). Again, if future enhancements are ever made to FdoISelect, the need to change each provider would be eliminated.
+    * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()''. Create an !FdoSelect base class and add default implementers for these methods. Then each provider would be changed to base their select command implementations on !FdoSelect instead of FdoISelect. To allow the join functionality to be fully integrated, two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilities would be named: !SupportsJoins() & !GetJoinTypes(). Again, if future enhancements are ever made to FdoISelect, the need to change each provider would be eliminated.
           * '''Pros''': this solution will not add more complexity to the API.[[BR]]
           * '''Cons''': We need to change all the providers leading to a big effort from everyone.
 
-     * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()'' with the default implementation of these methods throwing an exception. Providers which want to implement these new methods must override them and provide a detailed implementation. Even though FdoISelect is declared as ''interface'' we do not have real interfaces in the FDO C++ API, and abstract methods can co-exist with those that have a default implementation. A good example here are the locking methods on the select command. Most  providers do not support locking and have to provide an empty implementation (usually to throw an exception), creating more code on provider side. A better plan would have provided a default implementation in the FdoISelect base class. Following this idea, this alternative will just modify the FdoISelect base class, allowing providers that that will not support joins to remain unchanged. These providers will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. As with option 2 above: Two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilites would be named: !SupportsJoins() & !GetJoinTypes().
+     * Enhance FdoISelect, add two new methods ''!GetFeatureClassNames()'' and ''!GetJoinCriteria()'' with the default implementation of these methods throwing an exception. Providers which want to implement these new methods must override them and provide a detailed implementation. Even though FdoISelect is declared as ''interface'' we do not have real interfaces in the FDO C++ API, and abstract methods can co-exist with those that have a default implementation. A good example here are the locking methods on the select command. Most  providers do not support locking and have to provide an empty implementation (usually to throw an exception), creating more code on provider side. A better plan would have provided a default implementation in the FdoISelect base class. Following this idea, this alternative will just modify the FdoISelect base class, allowing providers that that will not support joins to remain unchanged. These providers will inherit the default implementation. Looking at FdoISelect there are already two methods which provide default implementation: !AddRef() and Release(), so adding default implementation for the new methods will not be something totally new. As with option 2 above: Two new capability functions will be added to the FDO FdoIConnectionCapabilities Interface so that applications can determine if a provider supports the join criteria and supported join types. These new capabilities would be named: !SupportsJoins() & !GetJoinTypes().
          * '''Pros''': this solution will not add more complexity to the API, we do not need to change any provider.[[BR]]
          * '''Cons''': None.
@@ -82 +82 @@
 }}}
 
-=== Selecting form Multiple Classes ===
+=== Selecting from Multiple Classes ===
 
 We should be able to select from multiple classes and have filters applied on any class attributes. In order to be able to achieve that objective, we can use FdoISelect::!GetFeatureClassNames() and add all classes we want to select from. The filter must be based on properties from the selected classes and filter can be validated at run time when the whole select is built. In this collection we can have:
@@ -376 +376 @@
     * "Class"."Property"
 
-This change is required in order to be able to support properies names having special characters, like: myClass."My Property" > 10. This change will not invlove any API change and will be done like a bug fix.
+This change is required in order to be able to support properties names having special characters, like: myClass."My Property" > 10. This change will not involve any API change and will be done like a bug fix.
 
 == Managed FDO API ==