Hi, still poking around the "create new feature type" code I'm not trying to implement the concept of a default store per workspace.
I basically assume I could draw a simple parallel with the default workspace handling when I stumbled in errors in how the REST config API handles the default workspace. Basically, if you try this it will work: http://localhost:8080/geoserver/rest/workspaces/default/ but if you attempt to drill down further it will start failing: http://localhost:8080/geoserver/rest/workspaces/default/datastores/<dsname> complaining datastore "default" does not exist. This is because the various finders do not perform any special handling of the "default" name and just assume "default" is actually a workspace name. Now, what to do? At the moment the default workspace is keyed in the catalog name -> workspace map as the one that has the null key. But the rest API gives it the "default" key. This can result in a clash too, what if you create a datastore that you name "default"? If we change the catalog code to use "default" as the key and forbid a workspace to be named that way we get at the same time: - a simplification of the rest code, no need for special handling of the "default" key in all finders and resources - avoid a chance to get a "default" named workspace that does not happen to be the default to be hidden by the special keyword handling in rest config. The same could follow 1-1 for the default store concept. Ah, code wise the default store (which would always be a DataStoreInfo) would be handled by: Catalog.setDefaultStore(WorkspaceInfo ws, DataStoreInfo store); DataStoreInfo getDefaultStore(WorkspaceInfo ws); Opinions? 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
