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. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
