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

[Basques, Bob (CI-StPaul)]

All,

I'm generally in favor of going with number 4.  I've been moving towards this way of setting up Mapfiles for the last couple of years.

Now having said that, I do have what I think is a good reason to keep the old FILTER container as a SQL fragment, I have used this as a process substitution using INCLUDE blocks.  This seems to work sometimes inside of a DATA definition, but fails more often than it works, but having the FILTER block available for adding to the SQL has proven useful to me in the past.  If the INCLUDE functionality were somehow possible to support inside of a SQL (seems/sounds real messy to me though), well then . . .

Are there other, similar, capabilities that might be missed by implementing option number 4?

Bobb


From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Lime, Steve D (MNIT)
Sent: Wednesday, September 24, 2014 8:31 AM
To: mapserver-dev at lists.osgeo.org
Subject: [mapserver-dev] One more decision related to 7.0/RFC 91...

So, when you get into implementation of an RFC you notice things. One thing that has come up is ambiguity around the way native SQL is specified. In older versions of MapServer  you'd set FILTER with a string value and the underlying driver would interpret that as SQL. Easy enough at first glance. RFC 91 aims to enable translation from MapServer expression syntax to native SQL plus handling FILTER merging with query operations. That's where the ambiguity sets in - it's not clear how you define native SQL, even the codebase handled it differently.

That ticket aims talks about ways to resolve this ambiguity and you can see the full discussion here:  https://github.com/mapserver/mapserver/issues/5001.  Ultimately we arrived at a point where we needed to bring the discussion back to the list.

Here's a summary of potential options:


1.       Do nothing, live with the ambiguity and resulting code complexity.

2.       Adopt the current OGR method of prefixing the FILTER string with "WHERE ".

3.       Adopt a new delimiter (e.g. <>) to explicitly define native SQL.

4.       Remove the ability to set native SQL altogether - FILTERs would use MapServer expression syntax only and we rely on translations.

Option 4 sounds drastic but probably gets us the most streamlined code to maintain - merging is much more straight forward. The native SQL in FILTER functionality was added long ago before more complex DATA handling was implemented. It's easy to argue that since all of the drivers that support some sort of SQL do so in the DATA definition that there's no need for native SQL FILTERs at all.

Why now? We'll we only want to break things at major releases so...

Steve

StEVE LIME  | DATA & Applications MANAGER
MN.IT Services @ MnDNR
651-259-5473 (w)  |  651-297-4946 (f) |  steve.lime at state.mn.us<mailto:Your.name at state.mn.us>

[cid:image001.jpg at 01CFD7DB.562B9460]<http://www.mn.gov/oet>

Information Technology for Minnesota Government   |   mn.gov/oet<http://www.mn.gov/oet>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140924/5cee5a45/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1611 bytes
Desc: image001.jpg
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140924/5cee5a45/attachment.jpg>