Hi,
trying to sum up the previous thread so that I have an
action plan (though I'm not sure I can actually act on
it in the short term).
First concept, the idea of having a default datastore
per workspace.
This requires a change in DataStoreInfo, we need a new
field in DataStoreInfo, some GUI to set the default store,
and some checks in the catalog that enforce a single
default store per workspace (pretty much the same as
having the default workspace).
Then we add the ability to create new feature types
in a data store (be it the default or named one) by
REST.
The changes needed to support field length, do you
see them as something we can do on 2.0.x?
Or is it better to make that only on trunk?
(more comfortable with the latter personally, and
try to push out a 2.1 sooner rather than later,
but this is a topic for another mail thread,
so if you want to discuss 2.1 release, please
start a separate one)
Then we do the same in the GUI, by adding an option
in the "new layer" page. In this case the GUI would
not use the default store concept, as we already
have a drop down where the user chooses the store.
Makes sense, since in that page there is no
contextual workspace, meaning there is also no
single default store.
Then I'd say we add the REST and GUI to drop a
schema. REST wise it's a delete, easy.
GUI wise I'd say we add a "delete" button
on the side of save and cancel, with a checkbox
offering the option to actually drop the
underlying storage if the store happens
to expose a "deleteSchema" method.
Method that will be added on the two common
superclasses we have today, ContentDataStore
and AbstractDataStore
Later, if we have time, we can think about
supporting update as well, both REST and GUI wise.
How does this sound?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.