I'm in disagreement with both the direction taken and the attitude shown, best to put an end to it and make it go through a formal GSIP instead (when someone has the resources to spend on both the discussion and implementation of it)
Regards Andrea Il gio 15 feb 2024, 20:19 Gabriel Roldan <gabriel.rol...@camptocamp.com> ha scritto: > 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
