<br><br><div class="gmail_quote">2010/11/8 Lime, Steve D (DNR) <span dir="ltr"><<a href="mailto:Steve.Lime@state.mn.us" target="_blank">Steve.Lime@state.mn.us</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;">
<div link="blue" vlink="purple" lang="EN-US">
<div><br><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">RFC-52: The changes I’d like to see are relatively minor (from a
coding perspective) and are a return to a single getShape() method in
MapScript. It will break 5.6 scripts but is simpler in the long run. I don’t
know that an RFC is necessary but I will start a ticket and we can go from
there.</span></p></div></div></blockquote><div><br>Steve,<br><br>Upon thinking about the one-pass query implementation for the mssql2008 driver I would also prefer to establish an additional parameter in msLayerWhichShapes which would denote the purpose of the query. Actually the driver may require to use a different fetching method if only a single-row forward only cursor is sufficient (which may be faster) or we would require to have subsequent random access to the result set. The latter would require to open the the query with the block cursor option at the client side which may be less performant for larger rowset sizes. <br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-US"><div><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">RFC-64: Needs feedback. This may push us back a week or two
depending on feedback. I think 6.0 is the right time to implement though given
the types of proposed changes. They are not candidates for minor releases.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p></div></div></blockquote><div><br>While I'm not sure about the recent implementation, I would highly support the efforts in RFC-64 in the way as Frank suggested earlier. In this case instead of using globals to represent the state, we could probably use the parse-param and lex-param directives to have a 'context' data structure something like in <a href="http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/gdal-rfc28/gdal/ogr/swq_parser.y">http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/gdal-rfc28/gdal/ogr/swq_parser.y</a> used for GDAL. This would make the parser thread safe without requiring a global lock around the operations and I would also expect a significant increment in the overall performance when rendering maps in multithreaded environments.<br>
<br><br>Best regards,<br><br>Tamas<br><br></div></div><br>