MS RFC 22a: Feature cache for long running processes and query processing (update)

[Frank Warmerdam]

Steve Lime wrote:
> Regarding RFC 22 what do folks think about implementing a simple one-pass cache using
> the resultCacheMemberObj for 5.0? Then considering RFC 22 independently of queries independently
> since there are plenty of good ideas there.

Steve,

I feel this would be prudent.

Earlier you wrote:

 > The result cache is nothing more than an array of those members.
 > (e.g. layer->results) That could be made more high performance and
 > hidden behind accessor methods in mapscript. Users use getResult(int i)
 > already.

I *think* this was in response to my claim that your approach would
mean all the mapscript scripts would be changed.  When I read it I
said "aha - my concern is moot".  But now that I review my one and only
mapscript script with queries I see that getResult() is just pulling
back the shapeindex and tileindex which I still pass to getShape().

So I still don't see how you can do your proposed change without
all mapscript scripts's approach to queries having to change.

Am I missing something still?

PS. My sample bit of script reads:

def dumpResultSet( layer ):
     layer.open()
     for i in range(1000):
         result = layer.getResult( i )
         if result is None:
             break

         print '(%d,%d)' % (result.shapeindex, result.tileindex)

         s = layer.getFeature( result.shapeindex, result.tileindex )
         for i in range(layer.numitems):
             print '%s: %s' % (layer.getItem(i), s.getValue(i))

     layer.close()

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org