[Mapserver-dev] Any experience with SQL Relay?

[Steve Lime]

Dave: I've been thinking about your first "ideally" statement alot
lately. I'm thinking that we might not need a caching mechanism. I think
we can extend MapServer FILTERs to support a few operators like
"intersects" (PostGIS would be easy since it's already there). Then we
can use the normal msLayerWhichShapes... and the next function. You
wouldn't even need query functions then, except perhaps for those that
need to find the "closest" of something. That function(s) only return
one shape so memory isn't an issue. The MapServer CGI would then behave
just like any the of the rendering code. Get a shape, run it through the
templates, repeat. No database return trips and no feature cache to
manage. 

The MapServer expressionObj's could maintain a hash/list/? of shapeObj's
to use within a FILTER. Non-spatially enabled datasets could use this.
Data sources like PostGIS, SDE and OracleSpatial could use their own
representations. MapScript could be exended to build these nastier
expressions.

Anyway, thinking out loud...

Steve


>>> David Blasby <dblasby at refractions.net> 06/23/04 12:16 PM >>>
Sean Gillies wrote:
> Thanks, Dave.  I think that we'd have to write new connector code that

> would
> be inspired by that in mappostgis.c, but using the sqlrelay API.  I'm
still
> undecided about starting in on this.

If you're going to do that, I suggest you make a "mapdatabase.c" file 
that would serve Oracle, PostGIS, SQLrelay, MySQL, and SDE layers. 
Having everything unified in one file would be a big help - only one 
place to test and find bugs...

"mappostgis.c" should be re-written instead of modified.

** Ideally I'd like to see the way the current query mechanism works be 
improved.  It might be worth experimenting with a "query cache" - it 
would significantly improve performance for all the DB layers, at the 
cost of cache memory.

** I'd also like to see the postgis layer *not* read all the results 
into memory.  This can be done with "FETCH N" instead of the current 
"FETCH ALL" commands on the cursor.  Ideally, you could thread the query

- improving performance and significantly cutting down on memory usage. 
  The threading portion is optional, but the "FETCH N" rows command is 
relatively simple...

dave
_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev