Hi,<br><br>I second to these concerns, absolutely. With regards to RFC 52 there have been a couple of breaking changes in MapServer 5.6 which prevents me from upgrading to this version in my existing projects. I've already tried to ring the bell in this topic with a couple of posts (see below), but it seems the use case described here (as keeping long term mapObj references) is not widely used and falls ouside of the general area of interest;<br>
<br><a href="http://n2.nabble.com/Ready-for-5-6-2-td4743344.html#a4746772">http://n2.nabble.com/Ready-for-5-6-2-td4743344.html#a4746772</a><br><a href="http://n2.nabble.com/OGR-single-pass-query-issues-was-Ready-for-5-6-2-td4753764.html">http://n2.nabble.com/OGR-single-pass-query-issues-was-Ready-for-5-6-2-td4753764.html</a><br>
<br>By raising up your issues below I've studied <a href="http://mapserver.org/development/rfc/ms-rfc-52.html">RFC 52</a> again to see the objectives, and it seems we are getting out of the sync with the current implementation at the drivers.<br>
<br>In my understanding with the original approach the driver should:<br><br>1. Retain the result set of the queries at the layer (ie. in the layerinfo structure) until the layer is open and no subsequent whichShapes is called to 'invalidate' the query.<br>
2. Provide such index in shapeObj which would allow to retieve in a subsequent resultsGetShape within the result set.<br>3. Retain the random access behaviour (getShape) for backward compatibility in parallel to resultsGetShape.<br>
<br><br>Since the RFC doesn't contain explicit note about the opposite, the drivers should also:<br><br>4. Preserve the behaviour of keeping separate set of results for separate layer instances. In this regard a query on one layer should not invalidate the results for a different layer instance of the same driver.<br>
5. Creating a clone of a layer should provide to use a separate query (by keeping the results intact on the original layer). This would be essential for msDrawQueryLayer to work when drawing the background before the highlighted features.<br>
6. Using a drawQuery should not invalidate the results of a previous query.<br>7. Drawing the map should not invalidate the results of a previous query.<br><br><br>Further notes: To provide correct implementations at the drivers it seems we should provide a bit more information for the driver to distinguish between the purpose of a query. For example whichShapes should take an additional parameter (querymode) with the following predefined values:<br>
<br>MS_QUERY_SEQUENTIAL:  The returned shapes will be retrieved by nextShape (no subsequent (result)getshape will happen). This would be used by the normal drawing operations.<br>MS_QUERY_RANDOM: The results would be retrieved by nextShape. The driver would provide oid-s as feature indexes to support to retrieve the features by the original (2 pass) behaviour (getShape). No features are retained at the driver for further access.<br>
MS_QUERY_PRESERVE: The results would be retrieved by nextShape and  resultsGetShape. The drivers should store the result set at the layer for further retrieval (1 pass).<br><br>The features retrieved by MS_QUERY_PRESERVE should be kept in a separate location either in layerinfo or in a separate structure (a queryinfo for example). The latter would provide the isolate the results from the layer opened state.<br>
MS_QUERY_SEQUENTIAL or MS_QUERY_RANDOM should not invalidate the results in queryinfo. <br><br><br>We should also provide the user with an option to select between the default of MS_QUERY_RANDOM/MS_QUERY_PRESERVE at layer level. Probably a layer processing option would be sufficient.<br>
<br><br><br>Best regards,<br><br><br>Tamas<br><br><br><br><br><br><br><br><br><div class="gmail_quote">2010/3/21 BrainDrain <span dir="ltr"><<a href="mailto:paulborodaev@gmail.com">paulborodaev@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Please read carefully.<br>
'old style' (two pass) query<br>
advantages:<br>
- in mapscript (c#) layer's query methods are CUMULATIVE (relative to other<br>
layer's queries). Query result (success/failure) has no effect on other<br>
layers when I call map.savequery.<br>
- In this case (query file contains just oid's) - I CAN create COMPLEX<br>
queries by applying different parameters and mixing query types<br>
- Query result is oid (or row index in shapefile) - it's cool for creating<br>
advanced attr. postqueries<br>
and disadvantages (insignificant):<br>
- query binary (closed) format? no output to string (only to file)<br>
- query file sensitive to layer indexes (map file cleanups/refinements/some<br>
normalization can cause query file incompatibility)<br>
- if server data changed refreshing map image by old url to cgi with<br>
queryfile parameter doesn't perform requery (need custom http<br>
handler/module)<br>
AND ONE PASS QUERY (RFC 52)<br>
advantages:<br>
- open query file format<br>
- speedup (no random access)<br>
disadvantages (huge):<br>
- layer's query methods are NOT CUMULATIVE (relative to other layer's<br>
queries). I CAN'T create COMPLEX queries (by using different<br>
attribute/spatial queries (metadata driven) for different layers)!<br>
- query result - some (shape)indexes and when I'm querying many layers in<br>
sequence I NEED TO PRESERVE QUERY FILE FOR EVERY LAYER (on success result)<br>
(!) and than on feature attributes (for some layer) demand (delayed request<br>
- its a normal behavior, for. ex I'm requesting only shape names for some<br>
layer which has results - to build results tree) I NEED to REQUERY this<br>
layer by using preserver file! DAMN!<br>
- there is no way to completely reproduce old mapscript behavior:<br>
  1. I need to determine primary key ("id") field name (for ex. search for<br>
"USING UNIQUE") - no need before!<br>
  2. I need to retrieve all attributes (put to some cache) by<br>
resultsGetShape to get right oid - it's not time saving operation - no need<br>
before!<br>
  3. I need to rerequest (!) feature attributes (or extract from custom<br>
cache) by layer.getFeature BUT for shapefiles this function implementation<br>
uses internal index (row position) - no id attribute (!) - and there is no<br>
function to get it!<br>
  4. NO WAY TO REPRODUCE COMPLEX QUERYING BY USING QUERYFILE CGI PARAMETER!<br>
(Am I right?)<br>
_________________________________________________________________________________________<br>
To SPEED UP random access in old style querying I was able to use "IN (...)"<br>
operator (I suppose that most time critical web apps uses postgis/ms sql<br>
spatial/oracle spatial which supports it)<br>
As for pt. 4:<br>
at this time I decided to output every layer query results to postgis<br>
service table (with session_id, map_id, layer_id, class_id, feature_id,<br>
geometry of any type (should I preserve attributes in a BLOB?)) and to<br>
handle data from this layer with 3 service map file layers<br>
(point/line/polygon) which populates dynamically (copying class styles with<br>
replaced colors for highlighting + using layer filter expression + using<br>
class expressions). I can shrink service table once in a month to support<br>
old session map files/url's.<br>
But I've created web UI to update data from browser (drawing, attribute<br>
editing) - so I need to update service table entries if corresponding object<br>
was updated (if I wand to see actual selection objects)<br>
<br>
I'm Disappointed....<br>
<font color="#888888">--<br>
View this message in context: <a href="http://n2.nabble.com/ONE-PASS-QUERY-RFC-52-FEATURE-OR-BUG-tp4775048p4775048.html" target="_blank">http://n2.nabble.com/ONE-PASS-QUERY-RFC-52-FEATURE-OR-BUG-tp4775048p4775048.html</a><br>

Sent from the Mapserver - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
mapserver-users mailing list<br>
<a href="mailto:mapserver-users@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/mapserver-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>
</font></blockquote></div><br>