I would prefer "delete" to capture the nice destructive nature of the activity (opposite of new).
Remove sometimes implies removing an item from a list (oppose of add). Jody On 09/03/2010, at 1:17 PM, Justin Deoliveira wrote: > On 3/4/10 4:29 PM, Jody Garnett wrote: >> I would add two distinct methods to Datastore: >> - updateSchema >> - dropSchema > Might be nice to agree on "delete" or "remove" rather than "drop" as the > latter makes the operation seem database specific. > >> >> The added clarity would be worth it. >> >> I would also consider extending the format of updateSchema so we can supply >> default expressions to the "new" columns. >> >> Jody >> >> >> On 04/03/2010, at 11:22 PM, Andrea Aime wrote: >> >>> Hi, >>> in OpenGeo we're looking into adding in GeoServer the ability >>> to create new feature types from a user provided description >>> by leveraging the data store createSchema(FeatureType) call. >>> >>> With this mail I'm trying to provide some ideas on the how >>> and gather feedback. >>> >>> The main idea is to have a GUI that allows one to compose a >>> feature type description and an equivalent REST call. >>> The GUI could be placed in the "new layer chooser", >>> now we have a >>> "add layer from"<datastore> >>> selection, I guess we could have a couple of radio buttons >>> instead providing also a >>> "create layer into"<datastore> >>> or something like that. >>> >>> The GUI would then offer the ability to add attributes, >>> name, data type, nullability and length. >>> >>> The REST api would allow to POST a description of >>> the feature type to >>> /workspaces/<ws>/datastores/<ds> >>> The description would come in the same formats >>> supported for the feature type >>> (see >>> http://docs.geoserver.org/2.0.x/en/user/extensions/rest/rest-config-api.html#feature-types) >>> >>> This would make it quite a bit easier to start >>> from scratch and allow data editing. >>> >>> Two things that are rolling in my mind are also how >>> to possibly handle something as simple as the human error. >>> >>> Say I made a mistake in the structure of the feature type. >>> How do I go and correct it? >>> DataStore and DataAccess provides updateSchema(), though I'm not aware >>> of any datastore actually implementing this call. For >>> a datastore >>> DataStore is also missing dropSchema() method, which sounds >>> quite like a strong limitation to this use case... I mean >>> being able to create a feature type by GUI and then have to go >>> on the database and issue a drop table manually seems backwards. >>> Dropping is also much simpler to implement than updating. >>> How do we go about to add this functionality though? >>> Shall we roll a new interface that contains only that method? >>> Or create a DataAccess2, DataStore2 subinterfaces that contains >>> it (oh the horror). >>> Or... but please be seated before reading this one... hijack >>> updateSchema and assume the user meant to delete the feature >>> type when we call updateSchema(Name, null)? >>> >>> The second thing is, would it make things easier if we mark >>> a datastore as the "default" and then have all schema management >>> calls hit it? >>> >>> 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 >> >> >> ------------------------------------------------------------------------------ >> 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 > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
