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.
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.
Justin Deoliveira ha scritto:
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.
Ok... and this far the REST api has not been touched one bit, and it
has already started working as it should (default handling working
everywhere by grace of the catalog doing so).
Are you suggesting I also add checks everywhere in the REST api for
the "default" keyword? As it seems to be suggested by "have REST rely solely on that assumption".
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
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.
Ok... and this far the REST api has not been touched one bit, and it
has already started working as it should (default handling working
everywhere by grace of the catalog doing so).
Are you suggesting I also add checks everywhere in the REST api for
the "default" keyword? As it seems to be suggested by "have REST rely solely on that assumption".
Re-reading your message, maybe you just meant that instead of
doing that just at the CatalogImpl level we should properly declare
at the Catalog javadoc level that "default" is reserved and what its
meaning is?
Is so I absolutely agree, I wanted to make that in the first place,
sorry I was no explicit about it
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On 4/26/10 1:38 PM, Andrea Aime wrote:
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
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.
Ok... and this far the REST api has not been touched one bit, and it
has already started working as it should (default handling working
everywhere by grace of the catalog doing so).
Are you suggesting I also add checks everywhere in the REST api for
the "default" keyword? As it seems to be suggested by "have REST rely
solely on that assumption".
Re-reading your message, maybe you just meant that instead of
doing that just at the CatalogImpl level we should properly declare
at the Catalog javadoc level that "default" is reserved and what its
meaning is?
Yup, this was what I meant.
Is so I absolutely agree, I wanted to make that in the first place,
sorry I was no explicit about it
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.