= !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 [wiki:MapGuideRfcs 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.