Rob Atkinson ha scritto:
> Hi
>
> I've been waiting for the basic app-schema capabilities to come on
> line so I can test them, after that my priority will be working out
> what to do with geomtryless - which relies on sql-datastore.
>
> I'm wondering whether I will be able to completely deprecate the
> geomtryless module by either:
> a) treating it as a special case of a complex attribute type composed
> of simple attributes, using the complex type support of app-schema
>
> or
>
> b) treating it as a special case of a SQL dialect
Mumble, jdbc-ng datastores and most existing jdbc datastores already
work fine against geometryless tables. What they miss is:
1) ability to connect to a random non spatial database using
only a jdbc driver
2) remap certain columns into geometries
3) handle sql queries as sources
1) and 3) I would very much like to see happen in jdbc-ng. 1)
seems easy, 3) is going to need some significant sponsoring I fear
(either in terms of work or funding).
2) seems a use case for a generic re-mapping datastore
(app schema maybe)
> In any case, the ability to create in-memory views, via SQL
> statements, seems valuable. The hope was it would be pushed into
> jdbc-ng, along with some date handling fixes currently in
> SQL-datastore which may be better handled in the SQL dialect handling.
>
> Possibly there is a prepared-statement approach that we should use
> (this is how we did complex features the very first cut at it)
Most jdbc-ng use prepared statements by default, thought postgis-ng
provides non prepared statement path as well (as an option) for
performance reasons. I explained why ps are (much) slower in some
other thread, but basically it boils down to the optimizer making
the access plan just once, assuming using the spatial index is
a good idea (for full table access is not).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
