Changes between Version 17 and Version 18 of FDORfc50

Timestamp:

Jun 3, 2010, 10:35:25 AM (14 years ago)

Author:

gregboone

Comment:

--

FDORfc50

@@ -306 +306 @@
 In order to be able to support sub-selects for '''IN''' operator we need provide a way to pass it through FDO Filter and make the parser to recognize the filter, since FDO Filter parser don’t know SQL syntax. The best way to achieve that is to pass a parameter in the filter, e.g.: ''!FeatId IN(:PARAM)''. This parameter will be replaced by the provider at execution time by the sub-select. This way we improve IN() operator in FDO to handle sub-selects.
 
-
-As new additions to the FDO API we will have three new classes (!FdoJoinCriteria, !FdoJoinCriteriaCollection and !FdoComputedClassIdentifier) and two enumerations (!FdoItemExpressionType and !FdoJoinType). We also need to add a new two new command capabilities, two new methods !SupportsJoins and !GetJoinTypes in order to be able to detect if those methods are supported by the provider (otherwise caller might get exceptions from the default implementation).
-
-We are planning at execute time to return a feature reader even there might be cases when the class returned by the reader might not have a primary key or a geometry column. In case select do not provide a select property list, all returned columns will be added to the feature class reader built at runtime, however in case user will request certain properties only those properties will be added to the feature class and even returned feature class might have no primary key or no geometry, depending of caller request. A feature reader is way more useful in applications. In the worst case we can add all primary keys from the selected classes to the result primary key of the class. Also in case there is no way to return a primary key user can add one of the property to the primary key collection of the returned class to have a primary key. The returned class will be read-only since there is no way to know what we can update.
-
-FdoISelectAggregates interface will be updated in the same manner in order to allow doing aggregates selects having sub-selects in the filter side.
+As new additions, the FDO API will define three new classes:
+    * !FdoJoinCriteria
+    * !FdoJoinCriteriaCollection
+    * !FdoComputedClassIdentifier) 
+
+and two enumerations
+    * !FdoItemExpressionType
+    * !FdoJoinType). 
+
+The API will also be updated to include two new command capabilities in order to be able to detect if those methods are supported by the provider. Otherwise caller might get exceptions from the default implementation.
+
+    * !SupportsJoins
+    * !GetJoinTypes 
+
+At FdoISelect::Execute time a feature reader will be returned, even though there might be cases when the join class returned by the reader contains a primary key or a geometry column. In cases where select commands do not provide a property selection list, all columns will be added to the feature class reader built at runtime. In cases where users request a subset of properties, only those properties will be added to the feature class, even if that means the returned feature class might then contain no primary key or no geometry properties. This behaviour will be implemented due to the fact that a feature reader, even one that does not contain primary key or geometry properties, is very useful in applications. In the worst case, the implementation can add all primary keys from the selected classes to the result primary key of the joined class definition. Also, in case there is no way to return a primary key, users can add one of the property to the primary key collection of the returned class to allow a primary key to be defined. NOTE that the returned class will be read-only since there is no way to know if the resulting class can be updated.
+
+FdoISelectAggregates interface will be updated in the same manner in order to allow performing aggregates selects having sub-selects in the filter side.
 
 Update and delete commands will not be changed to allow such complex filters, however we can update those commands doing a similar RFC in the future if is needed.