[mapserver-dev] 6.0 release plan

[Lime, Steve D (DNR)]

Regarding one-pass, would the contents of the queryObj suffice? It fully encapsulates the query (if it is indeed a query being done) and would be accessible through the layer's pointer back to the parent mapObj (layer->map->query).

Steve

From: Tamas Szekeres [mailto:szekerest at gmail.com]
Sent: Monday, November 08, 2010 3:06 PM
To: Lime, Steve D (DNR)
Cc: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] 6.0 release plan


2010/11/8 Lime, Steve D (DNR) <Steve.Lime at state.mn.us<mailto:Steve.Lime at state.mn.us>>

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.

Steve,

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.



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.


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 http://trac.osgeo.org/gdal/browser/sandbox/warmerdam/gdal-rfc28/gdal/ogr/swq_parser.y  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.


Best regards,

Tamas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20101108/ed9782fc/attachment-0001.html