Hmmm... some subtle issues indeed. I agree that the most sane thing would be to just send back an error when a name conflict occurs, giving the client the ability to specify a different name.
On Mon, Apr 23, 2012 at 11:21 AM, David Winslow <[email protected]>wrote: > Hi all, > > I'm investigating an issue I came across with respect to importing data > into existing datastores when data (shapefiles etc.) is uploaded through > the REST API. Currently the behavior is a little complicated to explain: > > 1) If no name conflict is detected, then the data is imported into a new > physical resource (say, database table) with a name derived from the name > of the uploaded file (so foo.shp => CREATE TABLE foo) > 2) If a physical resource of the same name is present in the target > datastore, then the data is put into that resource (either replacing or > appending to the existing data, depending on request parameters.) Actually > the name conflict check is done *after* this step, so the resource is > always modified. > 3a) If a featuretype of the same name already exists in the same > datastore, then the existing featuretype is used > 3b) If a featuretype of the same name exists in a different datastore in > the same workspace, a numeric suffix is appended to the native name to > derive a name for the GeoServer ResourceInfo that gets created. If this > suffix would need to be greater than 9, then GeoServer just gives up and > uses the _9 suffix, throwing an error when it tries to save. > 3c) If a coverage of the same name exists in the same workspace, then > GeoServer doesn't detect the conflict and errors when trying to save the > ResourceInfo again. > > http://jira.codehaus.org/browse/GEOS-5057 > > I think the new name conflict adjusting code I talked about last week[1] > can help with issue 3(a-c), but I think maybe some adjustment to the data > import behavior is in order as well. I think a simple, less confusing > behavior would be to *never* import data when there is a name conflict, > and simply error out in this case. > > A more complicated option would be to rearrange things so that the name > resolution happens before the data import, so that the name always matches > up with the created table. Why is this more complicated? It raises the > issue of what to do when a table exists that appears to have had its name > resolved previously: Say I have topp:states (a shapefile) and topp:states_1 > (a postgis table) and I try to import a shapefile into the postgis store > through the REST API. Should the shapefile be appended to topp:states_1 or > added as a new featuretype in topp:states_2? > > [1]: http://comments.gmane.org/gmane.comp.gis.geoserver.devel/16512 > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial.
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
