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

[Lime, Steve D (MNIT)]

Andreas: The more I've thought about this the more I like your idea. Drivers that support native SQL-like languages will potentially have to apply two filters, one from the processing directive and one from a transformed filter but that's easy to do, just and 'em together.. The advantage of the separating things is that the query functionality can work entirely in MapServer expression syntax and transform if necessary.

All CGI/FastCGI operations like mode=map, etc.. amodify the mapfile so separating configuration from runtime modifications is a bigger exercise. 

A filteritem can be modified at runtime using the map.layer[0]=FILTERITEM+'FOO' syntax assuming you have set proper validation.

Steve

-----Original Message-----
From: Eichner, Andreas - SID [mailto:Andreas.Eichner at sid.sachsen.de] 
Sent: Friday, September 26, 2014 3:52 AM
To: Lime, Steve D (MNIT); mapserver-dev at lists.osgeo.org
Subject: AW: One more decision related to 7.0/RFC 91...

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