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

[Tamas Szekeres]

2007/6/28, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> I think the easiest way to achieve one-pass queries would be to simply
> re-tool the result set structure to store a pile of features (linked list or other) in
> memory. The id cache could be maintained for memory constrained situations.
>

Steve,

I'm not totally sure about that. Then you should probably reimplement
all of the functions involved in the layerObj->results member. At
least the following files might be affected:

mapdraw.c
mapquery.c
mapgml.c
mapogcfilter.c
mapogcsos.c
maprasterquery.c
maptemplate.c
mapwms.c

And it's quite difficult even to count the existing functions to be
modified. I guess it's
a large amount of work to implement this as well as fixing the bugs it involves.

> That doesn't get us past the other 80% issues, but might it simplify the implementation
> of the rest and avoid user confusion with having to set up alternative layers and
> such?
>

It would make the interface backward incompatible so the user should
modify all the scripts
involved in the result cache handling. They should use some other
method to retrieve the shapes than the GetShape of the provider which
is currently used.

Best regards,

Tamas