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

[Lime, Steve D (MNIT)]

I appreciate the perspective and comments. Your need is along the same lines as Bob's. A separate native filter could have merit although it doesn't help the case w/shapefiles although that's were filter merging is easiest. Part of the problem is that I'm trying to cram everything into layer->filter. Maybe using a second, layer->qfliter or something like that would be better. Then the drivers could apply both... The merging code where we'd see the simplification is limited to one function in mapquery.c (and it works) so it's probably not worth it at this point. That points me more towards the new delimiter syntax, <>'s.

IMHO filter items are quite useful. It's common to switch the item dynamically but not the expression itself - much easier to secure as well. 

Steve

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

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