I am not so big on the idea of making the catalog store the default workspace under the "default" key and have REST rely solely on that assumption. I would rather this be enforced at the catalog api level and allow any catalog implementation to represent the default as they choose so it can remain an implementation detail.
So I think the following would work: (a) prevent the user from creating a workspace named "default" and have it be truly a reserved identifier (b) Update the api for Catalog.getWorkspaceByName(String) to handle null or "default" as meaning the default workspace. 2c. -Justin On 4/26/10 5:06 AM, Andrea Aime wrote: > 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 > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
