Changes between Version 6 and Version 7 of MapGuideRfc123

Timestamp:

11/02/11 09:37:37 (13 years ago)

Author:

jng

Comment:

--

MapGuideRfc123

@@ -64 +64 @@
 '''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.
+ * The extended class is being queried with only one aggregate function: SpatialExtents(). See the section '''Aggregates''' for an explanation of why we're only supporting this one function.
 
 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.
@@ -127 +127 @@
 === Aggregates ===
 
-If a SelectAggregates operation is invoked on an extended feature class, the same FDO join optimization condition checks are done against the extended feature class and its feature source.
+If a SelectAggregates operation is invoked on an extended feature class, the same FDO join optimization condition checks are done against the extended feature class and its feature source and the same extended select command is executed.
 
-In addition to normal select aggregate command processing, the same join criteria and join filter processing will be applied to the select aggregate command.
+However, we house this reader within an FDO Expression Engine DataReader (which is housed within a MgServerDataReader) allowing us to use aggregate functions against an FDO-joined query result.
+
+The reason for supporting aggregates is to ensure that we can use SpatialExtents() on extended feature classes. This is what the Feature Source Previews uses to obtain a usable MBR for previewing. Thus aggregate function support in this RFC is only limited to supporting SpatialExtents() and nothing more.
+
+'''NOTE: It was originally planned to use FdoISelectAggregates with the new join criteria APIs (so the final query can be executed natively at the data store level), but it has come to our attention that support for SpatialExtents() in a select aggregates command is a case that is not yet covered by the providers that currently support these APIs. Thus the Expression Engine serves as a fallback approach until such cases are supported commonplace.'''
 
 == Implications ==