Hi Ben,
I’ll be giving a shot to app-schema support on trunk and am wondering if there’s already any backend that supports SQL queries as the source of data, like we did with the SQLDataStore interface on the complex-features branch?
cheers,
–
Gabriel Roldan
http://www.opengeo.org
Not that I know of, Andrea and I talked about doing this for jdbc-ng but never got around to it.
Gabriel Roldán wrote:
Hi Ben,
I'll be giving a shot to app-schema support on trunk and am wondering if there's already any backend that supports SQL queries as the source of data, like we did with the SQLDataStore interface on the complex-features branch?
cheers,
--
Gabriel Roldan
http://www.opengeo.org------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
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
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)
Thoughts and advice welcome.
On Wed, Apr 1, 2009 at 4:17 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Not that I know of, Andrea and I talked about doing this for jdbc-ng but
never got around to it.Gabriel Roldán wrote:
Hi Ben,
I'll be giving a shot to app-schema support on trunk and am wondering if
there's already any backend that supports SQL queries as the source of
data, like we did with the SQLDataStore interface on the
complex-features branch?cheers,
--
Gabriel Roldan
http://www.opengeo.org------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldán wrote:
I'll be giving a shot to app-schema support on trunk and am wondering if there's already any backend that supports SQL queries as the source of data, like we did with the SQLDataStore interface on the complex-features branch?
Gabriel, the only thing I know of is GeoTools trunk modules/unsupported/sql-datastore. I have never tried to to build let alone use it. It has your name in the pom, so I suspect that it was forked from the 2.5 community-schemas as some point.
What are you trying to do? You will need to apply the GEOS-2753 patch if you want any WFS responses for feature types whose name does not match their schema type name. Encoding is still broken, but getting close ...
Today I will commit some tests that may be of interest to those exploring app-schema.
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
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-schemaor
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.