Two wrongs don't make a right, IMHO. I'd rather break convention than introduce such a dangerous parameter to an existing API endpoint and change its semantics
I'm not talking about a rewrite of the REST API, but a new verb to the existing API. Don't see how that'd make it harder for the people that's used to it, when it doesn't even exist. Used the the rest api having all sorts of parameters I take it. So how much harder is it when I ask "how do I delete a table in my database?" - oh, just need to add this param to DELETE ../stores/mystore/featuretypes/xxx - or, oh, just need to call DELETE ../stores/mystore/drop/xxx For the former, you need to update the documentation saying if you pass this, then it does this, if you pass this other parameter then it does this other thing. Beware to check all your scripts, because if you accidentally leave this parameter on, your company database will be destroyed. As opposed to not changing the current api and adding an endpoint that says: This will delete the database table. Fails in case there's an existing FeatureType using it. My point is this deserves its own endpoint. Way more explicit and less error prone than a new param to the current delete featuretype operation, which would change its semantics so drastically. In any case, that's just my opinion. Cheers, Gabe *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS *Gabriel Roldán* Geospatial Developer On Thu, Feb 15, 2024 at 1:18 PM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > On Thu, Feb 15, 2024 at 3:00 PM Gabriel Roldan <gabriel.rol...@gmail.com> > wrote: > >> I mean "increases complexity and difficults understanding", of course. >> > > But parameters are already widely used in the GeoServer REST API, and > "cascade" is used in other places as well. > This would be breaking convention, making the API harder to use for those > that are already used to it. > > Don't get me wrong, I know the GeoServer REST API is old and would need a > rewrite, but that's the key point, a rewrite would be the time to break > compatibility and adopt new ways of doing things. > > >> >> >>> 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? >>> >> > The REST API only returns configured feature types by default. There is > (guess what?) a parameter in the "featuretypes" resource, called "list", > that can take > 3 different values: > > - "configured" (default if not specified): only lists the configured > feature types (links to the feature type info resource) > - "available": returns the native feature types not yet configured > (mind, only their names) > - "available_with_geom": same as above, bon only spatial ones > - "all": returns all of them, configured or available (again, just > names) > > The FeatureTypeController delete mapping already has a "recurse" flag to > delete layers while the feature type is removed. > Now here there is a risk of confusion between "recurse" and "cascade", a > "removeData" flag would probably avoid confusion. > > Cheers > Andrea > > == > > GeoServer Professional Services from the experts! > > Visit http://bit.ly/gs-services-us for more information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions Group > phone: +39 0584 962313 > > fax: +39 0584 1660272 > > mob: +39 339 8844549 > > https://www.geosolutionsgroup.com/ > > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > > Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE > 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si > precisa che ogni circostanza inerente alla presente email (il suo > contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è > riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il > messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra > operazione è illecita. Le sarei comunque grato se potesse darmene notizia. > > This email is intended only for the person or entity to which it is > addressed and may contain information that is privileged, confidential or > otherwise protected from disclosure. We remind that - as provided by > European Regulation 2016/679 “GDPR” - copying, dissemination or use of this > e-mail or the information herein by anyone other than the intended > recipient is prohibited. If you have received this email by mistake, please > notify us immediately by telephone or e-mail > _______________________________________________ > 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 >
_______________________________________________ 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
