Changes between Version 5 and Version 6 of MapGuideRfc123

Timestamp:

10/27/11 08:55:22 (13 years ago)

Author:

jng

Comment:

--

MapGuideRfc123

@@ -41 +41 @@
 == Proposed Solution ==
 
-The solution consists of 3 parts:
+The solution consists of 4 parts:
 
  * Testing for the FDO join optimization path when performing a SelectFeatures() call against an extended feature class
  * Setting up the FDO join query.
  * Handling the iteration logic for the results of a FDO join query.
+ * Handling aggregates
  
 Each part is explained in detail below.
@@ -53 +54 @@
 When performing a feature query against an extended feature class that consists of joins, use the FDO join APIs if the extended feature class satisfies the following criteria:
 
+'''Regular selects'''
+
  * The Feature Source this extended feature class belongs to supports joins (ie. The SupportJoins capability returns true)
  * The Feature Source this extended feature class belongs to joins with another feature class from '''the same feature source''' (this is because FDO Joins work within the context of the same connection). The feature class being joined on cannot itself be an extended feature class.
  * The extended feature class only contains one join. Supporting chained or multiple joins is beyond the scope of this RFC.
- * If this extended feature class is being queried with a filter, the filter does not contain any references to properties on the feature class to be joined on.
+ * If this extended feature class is being queried with a filter, the filter does not contain any references to properties on the feature class to be joined on. This is because there is no way I am aware of in the FDO Join API to apply filters to the non-primary sides of the join.
  * The type of join being performed is supported by the underlying FDO provider. 
+
+'''Select Aggregate'''
+ * All the above conditions
+ * The extended feature class is being queried cannot have 1:1 forced on it unless the aggregate function is SpatialExtents(), Min() or Max(). This is due to my current findings where an FDO select aggregate operation that contains an aggregate function can produce incorrect results because there is nothing in the FDO select aggregate API equivalent to the force 1:1 behavior. Including the identity properties of the primary class in the query with the distinct flag activated does not produce the intended results. The reason SpatialExtents(), Min() and Max() is exempt is because duplicated primary class features won't affect the final aggregate result with these functions, thus these aggregate functions are safe to use, whereas other aggregate functions like Sum() or Avg() would produce distorted results from the duplicated primary class features.
 
 If any of the above criteria is not met, the extended feature class in question is considered not to meet the FDO join requirements and is delegated off to the GWS Query Engine as it currently is.