Changes between Version 2 and Version 3 of FDORfc50

Timestamp:

06/02/10 11:05:54 (15 years ago)

Author:

gregboone

Comment:

--

FDORfc50

@@ -43 +43 @@
      *  '''Cons''': We need to change all the providers leading to a big effort from everyone.
 
- * 3. Enhance FdoISelect, add two new methods ‘!GetFeatureClassNames()’ and ‘GetJoinCriteria()’ with a default implementation throwing an exception. Providers which want to implement these new methods just can override then and provide a detailed implementation. Even FdoISelect is declared as ‘interface’ we do not have interfaces in C++ and we can have all other abstract methods and only the new one with a default implementation. A good example here would be locking methods from select command: most of the provider do not support locking and have to provide an empty implementation (usually to throw an exception), so more code on provider side when we could just provide a default implementation in the base class. Following this path we just modify the base class and all other providers will not be changed since 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.
+ * 3. Enhance FdoISelect, add two new methods ‘!GetFeatureClassNames()’ and ‘!GetJoinCriteria()’ with a default implementation throwing an exception. Providers which want to implement these new methods just can override then and provide a detailed implementation. Even FdoISelect is declared as ‘interface’ we do not have interfaces in C++ and we can have all other abstract methods and only the new one with a default implementation. A good example here would be locking methods from select command: most of the provider do not support locking and have to provide an empty implementation (usually to throw an exception), so more code on provider side when we could just provide a default implementation in the base class. Following this path we just modify the base class and all other providers will not be changed since 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.
      *  '''Pro''': this solution will not add more complexity to the API, we do not need to change any provider.
      *  '''Cons''': None.
@@ -53 +53 @@
 We need to define supported cases and all necessary classes need to be added:
 
- * A. '''Selecting form 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 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:
+ * A. '''Selecting form 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 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:
      *  FdoIdentifier’s in case we just need to pass a class name.
-     *  FdoComputedIdentifier’s having a name and as expression value a FdoIdentifier, this way we can get aliases, e.g. PropName AS NewPropName. We already use computed identifiers in our API for expressions and we provide a name and an expression value. In this case it will be the same, since an alias is actually an expression: we provide an alias (name) and the real name of the property.
-     *  FdoClassComputedIdentifier’s which is a FdoISelect having a name. This option might not be supported by all RDBMS providers and it depends of the internal implementation. This class behaves like a computed class which will be evaluated at run time and really depends of the provider implementation. This new class will help to define sub-selects, see below case (C)
+     *  !FdoComputedIdentifier’s having a name and as expression value a FdoIdentifier, this way we can get aliases, e.g. PropName AS NewPropName. We already use computed identifiers in our API for expressions and we provide a name and an expression value. In this case it will be the same, since an alias is actually an expression: we provide an alias (name) and the real name of the property.
+     *  !FdoClassComputedIdentifier’s which is a FdoISelect having a name. This option might not be supported by all RDBMS providers and it depends of the internal implementation. This class behaves like a computed class which will be evaluated at run time and really depends of the provider implementation. This new class will help to define sub-selects, see below case (C)
 
 We will use some SQL examples just to illustrate things we are trying to achieve, each RBDMS-based provider will translate FDO selects in server side SQL depending of the server capabilities.
 
-'''SELECT * FROM class1 AS p1, class2 AS p2 WHERE p1.ID=p2.FeatId AND SPATIAL_COND(p1.GEOM, GEOM_VAL);'''
+'''SELECT * FROM class1 AS p1, class2 AS p2 WHERE p1.ID=p2.!FeatId AND SPATIAL_COND(p1.GEOM, GEOM_VAL);'''
 
 Below we added some C++ code on how caller can use this new improvement to achieve above select statement:
@@ -81 +81 @@
 }}}
 
-'''Note:''' In the base class we have a method named GetFeatureClassName, in case caller will use it and the FdoIdentifier is not added into GetFeatureClassNames we can add it at Execute time.
+'''Note:''' In the base class we have a method named GetFeatureClassName, in case caller will use it and the !FdoIdentifier is not added into !GetFeatureClassNames we can add it at Execute time.
 
 
@@ -281 +281 @@
 Named sub-select will be used to generate SQL commands, like:
 
-'''SELECT * FROM point WHERE  FeatId IN (SELECT pt.FeatId FROM pt WHERE pt.FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL));'''
+'''SELECT * FROM point WHERE  !FeatId IN (SELECT pt.!FeatId FROM pt WHERE pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL));'''
 
 In above case we will have two selects having following filters:
-    * Main select:  “FeatId IN(:SUBSEL)”
-    * Sub-select: “pt.FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)”
+    * Main select:  “!FeatId IN(:SUBSEL)”
+    * Sub-select: “pt.!FeatId >= 2 AND SPATIAL_COND(pt.GEOM, GEOM_VAL)”
 
 Below we added some C++ code on how caller can use this new improvement to achieve above select statement: