[mapserver-users] RFC 74 "DBINCLUDE"

[Robert Hollingsworth]

Steve, 
Thanks for your suggestions; some comments inserted after the numbered items below.  My general response is that I would like to get some more detailed sketches of some of these capabilities you have in mind, especially for #1 and for what I numbered as (6).


On 6/12/2013 5:20 PM, Robert Hollingsworth wrote:
>> I'm looking at implementing RFC 74 "Includes from non-file connections,"
>> ...
>> I'd invite interested parties to look at the RFC and
>> comment back with possible additional use cases, to see how well the
>> prescribed mapfile syntax for this supports those uses.

>Hi Robert,
>
>Here are some thoughts on this:
>
>1. We may want to be able to pass additional mapserver variable 
>into the SQL. For example the BBOX of the request classification can 
>be limited to that extent. SCALE of the map request so different 
>tables can be
 configured based on the SCALE.
>
the RFC seems to imply 'yes' to this in general (with possible limitations that would be addressed by my comments to #2 below?), and that would be my inclination.  I need to review the variables documentation to speak more authoritatively on the subject.
>
>2. If I need to perform a complex join and other complex SQL 
>can I do that using the DATA statement like I can now as a sub-select?
>
the RFC suggests composing a query from the DATA, INCLUDEITEM, and FILTER, but I think I'd prefer to simply have the DATA statement carry all the information as the literal query (plus the variables substitution) rather than have it composed from pieces.  Perhaps if the query results in a single column, then that is taken automatically to be the text inserted to mapfile.  So I'd think no particular limit on the complexity of the query in DATA.
>
>3. Can these be embedded in a regular INCLUDE and vica versa?
>
from looking at the code (maplexer.l), seems that it would actually be cleaner to allow file includes to contain db includes, and allow db includes to contain file includes.  There's an arbitrary include depth of 5 at the moment.  The design seems to center on a notion of 'resolve this to literal mapfile syntax RIGHT NOW and insert into the the stream and continue.'

if this scheme were to expand to allow includes from a URL, I'd think same tolerance for mixed includes would apply.
>
>4. How would we pass USER into the request? via normal 
>mapserver variable substitution? via the webserver authenticated user?
>
will have to research further
>
>(5) You might want to add these to the RFC, it is common to include 
a section in the RFC to track ideas that are outside the scope of the 
>project and comment on why.
>
good idea.  I'd say the scope is not set in concrete at this point.  I think would be wise to simply require that the query fully resolves to a block of legal mapfile syntax, however it manages to do so from whatever mix of literal SQL, whatever is stored in the data tables that are being queried, and whatever variable substitutions.  And that all this resolves from the INCLUDE block alone, rather than permitting/requiring other mapfile constructs to react to the results from the query. 
>
>(6) One of the things that has been asked for in the past is 
>"named styles" ie: reuseable named snippets, like highways, toll-roads, 
>major->roads, minor-roads, streets, or points of interest 
>by "type", etc. It seems like this would allow for that and an example 
>demonstrating this would be
 ideal.
>
would definitely like to hear more from you on this.  One thing occurs to me, this mechanism might definitely help where the combinatorial styling gets really dense, say, picking symbol/color/labeling/etc based on several column values ('type' 'status' 'owner' etc) each with a large number of legal values.  I'm also intrigued by what was suggested in the RFC, namely setting the exact number and expression of CLASS based on actual distinct data values at the moment.

thanks again,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20130614/d96f3201/attachment.htm>