Changes between Version 8 and Version 9 of MapGuideRfc123


Ignore:
Timestamp:
Nov 7, 2011, 8:10:31 AM (12 years ago)
Author:
jng
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc123

    v8 v9  
    1010||RFC Template Version||(1.0)||
    1111||Submission Date||24 October 2011||
    12 ||Last Modified||24 October 2011||
     12||Last Modified||8 November 2011||
    1313||Author||Jackie Ng||
    1414||RFC Status||draft||
    … …  
    5858 * The Feature Source this extended feature class belongs to supports joins (ie. The SupportJoins capability returns true)
    5959 * 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.
     60 * The query options cannot contain computed expressions based on secondary class properties.
    6061 * The extended feature class only contains one join. Supporting chained or multiple joins is beyond the scope of this RFC.
    6162 * 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.
    … …  
    146147The 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.
    147148
     149Another special case with aggregate functions is the need to fetch distinct values. The UNIQUE() aggregate function is used by Maestro/AIStudio to fetch distinct values to generate themes. As performance with this function is generally respectable in its current form, if this function is detected in the aggregate query options, and the extended class being queried is capable of FDO joins, we will take the regular query path instead of the FDO join one. This is mainly to avoid the currently un-handled case of computed expressions on prefixed secondary properties in the FDO join path.
     150
    148151'''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.'''
    149152