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

[Eichner, Andreas - SID]

Steve,

I can not see a problem with that. Just move the native filter to a processing option. Then FILTER will be used either as mapserver expression or in combination with FILTERITEM. As proposed in the RFC the layer->filter will hold the resulting unified mapserver expression merged from the filter specified in the mapfile and a filter build from request (attribute query). As described in the RFC data source drivers are then able to transform that filter into a native one. But it should be pretty simple for them to take the translated filter and append an additional filter part from a processing option ("NATIVE_FILTER") and AND them together. I would prefer a processing option instead of special delimiters or similar constructs as it really is a driver specific extension which only a few support and yes, these filters are not portable. When I take a look at PostGIS/Oracles DATA parser code it makes me cry thinking a script should break it into parts, merge a filter in and rebuild the DATA string...

Using a separate field which will be used internally to hold the final filter is probably a good idea. It is a problem that a mapserver request modifies the mapObj. Currently WFS queries modify the layer->filter, the WMS-BBOX filter modifies the map->extent and so on. This requires a mapObj be reloaded for every request. In the Apache module I use currently cloning of a mapObj to avoid reloading from file but that's still not optimal. Would be great to see mapObj be treated as configuration and therefore read only one day.

BTW using FILTERITEM to switch the queried attribute must be done by runtime substitution, ie. FILTERITEM %item%, right? Isn't it much the same as FILTER "[%item%] ~ 'value'"? Dropping FILTERITEM was just an idea but I have no problem with keeping it.


Greets