> > * Flag parameters are bad design, increases complexity and understanding, > breaks a couple principles. > I mean "increases complexity and difficults understanding", of course.
> question arises of how to determine which table to delete once you deleted > the FeatureType. I guess it should be an operation of the DataStore and not > of the FeatureType, and use the FeatureType's nativeName to distinguish? > Which makes me thing, if I'm not mistaken, there's no REST endpoint to gather the list of a DataStore's **native** feature types. Like if you wanted to create a rich client app using strictly the REST API, how would you list the store's available feature types? with that in mind: GET ../<workspace>/stores/<store>/nativeFeatureTypes would give you a list of raw type in the store GET ../<workspace>/stores/<store>/nativeFeatureTypes/<nativeTypeName> its raw FeatureType DELETE ../<workspace>/stores/<store>/nativeFeatureTypes/<nativeTypeName> would drop the native FT. Possibly failing if it's in use, or cascade deleting published feature types for that native type (table) opinions?
_______________________________________________ Geoserver-users mailing list Please make sure you read the following two resources before posting to this list: - Earning your support instead of buying it, but Ian Turton: http://www.ianturton.com/talks/foss4g.html#/ - The GeoServer user list posting guidelines: http://geoserver.org/comm/userlist-guidelines.html If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
