MapGuide RFC 46 - New Generate Filters API

This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	(Date/Time submitted)
Last Modified	(your name here) Timestamp
Author	Ronnie Louie
RFC Status	draft
Implementation Status	pending
Proposed Milestone	2.1
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1

Overview

This RFC is for adding a new API for generating filters from a selection.

Motivation

The current MgSelectionBase::GenerateFilter() API returns a string representing a filter for a set of selected features. This filter string would look something like: "FeatId = 1109 OR FeatId = 1130 OR FeatId = 2065" such that each of the IDs of the selected features is explicitly specified. The string is then passed as the filter to MgFeatureService::SelectFeatures() to query the datastore.

A selection can contain an unlimited number of features, which means that the filter will contain an unlimited number of OR conditions. However, most datastores have a finite number of OR's that can be supported, and some data sources, such as Access databases, are limited to a relatively small number or OR conditions.

Results can be unpredictable when the limit is exceeded due to buffer overruns and/or memory corruption leading to instability in the MapGuide Server. In an effort to improve stability, GenerateFilter() was modified to return a string representing a smaller subset of the total selected features.

Proposed Solution

This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, XML schema changes, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed.

Implications

This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.

Test Plan

How the proposed change will be tested, if applicable. New unit tests should be detailed here???

Funding/Resources

This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change.