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

[Steve Lime]

Your script would still work since we would set shapeindex and tileindex so a call to getShape()
would still work. It would just be inefficient.

Steve

>>> On 6/29/2007 at 2:34 PM, in message <46855EC0.7090507 at pobox.com>, Frank
Warmerdam <warmerdam at pobox.com> wrote:
> 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,