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

[Steve Lime]

That could be as simple as the shape just sitting there along with the indexes, that is, the
resultCacheMemberObj gets a new member, a shapeObj.

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. 

>>> On 6/28/2007 at 12:25 PM, in message <4683EEFD.9040700 at pobox.com>, Frank
Warmerdam <warmerdam at pobox.com> wrote:
> Steve Lime wrote:
>> I think you start bleeding over into a full-blown feature cache as described. 
> That's kinda why I
>> was thinking of using the resultcache. You wouldn't even need msGetShape 
> then, the shape 
>> would be there for you as you rolled through the feature cache...
>> 
>> (deadline, schmeadline)
> 
> Steve,
> 
> But all the code that uses the resultcache would need to know to use
> the shape directly instead of calling msGetShape().  It would break
> all mapscript applications that do queries for instance.  It seems
> like a needlessly disruptive approach.
> 
> It doesn't *have* to bleed over into a full blown feature cache.
> 
> Best regards,