On Mon, Apr 23, 2012 at 7:23 PM, Justin Deoliveira <[email protected]> wrote: > 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. +1. Simpler, cleaner.
> > 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 > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
