Hi, I'm looking into how to integrate the sql query to feature type support in GeoServer.
At first I was thinking to use a datastore parameter structured like a property file, but it's a quite clunky approach. The definition in the property file would have been something like: virt=select a, b, c, the_geom from realtable where a > 3 virt.pk=a,b virt.geom.the_geom=POINT,4326 Basically it's the query, plus information about which attributes are part of the primary key, plus information about what type the geometry is. Instead of this I would like to have a configuration GUI (and one less parameter in the never-ending list of params for JDBC data stores). First approach: starting from the "new layer" panel ------------------------------------------------------- Ideally, a user would go to the layer list, choose "new layer", and upon choosing a JDBC data store he would be presented with the option to create a feature type by SQL using a SQL query as the definition of it. The next page would provide the user a text area in which he could edit the query, and a "test" button which would both test the query for validity and provide a GUI to setup the primary key fields and the geometry details (more or less a table of the attributes, with name, type, a checkbox to make a field part of the pk and the possibility to edit what we know about the geometry). Past that the user would get into the usual layer page, which would sport a new panel, equal to the contents of the previous page, to allow editing of the sql and details. Implementation wise I would like to store the sql query as part of the FeatureTypeInfo metadata map. Now, the issue is, what do we do on restart? We'd need to configure the sql in the data store again, and to do so we'd need either the resource pool to do so, making it aware of the sql definitions, or a callback that would configure the existing sql feature types into it by inspecting the FeatureTypeInfo associated to the store. Second approach: starting from the datastore config panel --------------------------------------------------------- In this case, we make a custom GUI to configure the JDBC data stores that has a list of the existing sql definitions and allows to add/edit/remove them. On add the workflow would be the same as above, but we won't show an edit panel in the existing layer definition. The set of sql definitions would be stored in the property file like parameter I described at the beginning of the mail, we'd just provide a nicer GUI for it. The upside is that we would not need to touch the ResourcePool, the downside is that the workflow would be less natural to the user imho, especially now that we're about to add the ability to create a new feature type in the "new layer" page as well (see GSIP 47) Oh, in any case the work would be done on trunk only. What do you think? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
