Thoughts on a feature cache for queries...

[Tamas Szekeres]

Steve,

I continue to think that the layervtable is the most feasible place
where this effort can easily be undertaken. In the recent days I've
just been planning to make some tests in this regard and find out how
to simplify RFC22 to show that this implementation isn't as large as
it seems at the first sight (I consider that was the primary reason of
the abstention from this idea so far, shoulda' recall that thread
again).

Moreover I'm pretty involved in such change that provides not only a
particular implementation to a specific problem, but also a framework
for altering the behaviour of the existing providers in an unique
fashion. Some possible use cases have already been described like:
- Constructing geometries based on feature attributes
- Modifying the geometries or the feature attribute values
- Geometry transformations (like GEOS operations)
- Feature cache
- Providing default layer style based on external style information,
or attribute based styling
- Providing custom data filters

I consider most of these implementations should be pluggable external
and separate from the mapserver core.

Following the line of the feature cache approach the following issue
might have to be considered:

1. When retrieving the shapes from the provider the ownersip of the
shape is considered as being the caller. Therefore an additional
shapecopy is to be done regardless of the fact that all of the shapes
of the previous query are retained in the memory.
2. Currently the number of the items retrieved upon a normal query or
drawing operation might vary. Therefore every shape retrieval might
require to fetch all of the relevant items in any case.

As thinking the problem further we should not think this effort only
as a performance boosting solution. I can see most of the mapscripters
are involved in monkeying with inline layers having the query results
retained for the further renderings most of the time. As far as I
remember this issue was the most compicated effort when I started to
deal with the mapscript interface at the first time. Isn't it worth
considering to establish some kind of internal support to accomplish
this task? We would also require to have a mapscript support for
retrieving the shapes from the cache by reference so as to modify the
existing data and rendering the modifications automatically upon the
subsequent drawing operations.

Best regards,

Tamas



2007/6/6, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Hi all: What would folks think about implementing a simple feature cache for storing query results? I know Tamas has something grander planned but it seems a ways off and implementation with queries may be problematic anyway. We could use the featureList structures that form a linked list containing shapeObj's. I've always been a bit hesitant to do this because with large datasets you could use a ton of memory, but the performance bottlenecks with the two-pass query probably out weigh that problem. If folks are somewhat positive about the idea I'd be glad to work up an RFC...
>
> Steve
>