[mapserver-dev] One more decision related to 7.0/RFC 91...

[Eichner, Andreas - SID]

Hi,

I dislike the idea of loosing the native filters as not everything is written down in mapfiles. Simple example: I have a script to generate a layer with features selected by an Oracle Application Express Interactive Report. That works by using some query parameters to find the active filter options for this report from the database, turn them into a valid SQL filter string, load the specified mapfile and apply that filter string to the specified layer's FILTER. For such use cases it would be a pain to use DATA as that uses a wired syntax.
To transparently apply an additional native filter and to avoid ambiguities a NATIVE_FILTER statement could be added. As this filter would be transparently added to every query by the underlying driver it shouldn't interfere with the rest of mapserver and therefore might even be implemented as PROCESSING option "NATIVE_FILTER=...". Dropping this functionality completely is IMHO a no-go but moving it to a different place with 7.0 is OK.
This would solve the ambiguity that FILTER is a mapserver expression for one driver and native SQL for the other. I personally would drop FILTERITEM and use FILTER exclusively as it seems to give no benefits and only raises confusion when to use which construct.

Kind regards