I sorry you feel that way Andrea. >From my point of view, there's no direction taken but an open and honest discussion. And I can't see how my attitude is bad at all, given there's absolutely no personal direction on any of my comments. I've a strong opinion on the matter, yes. How relevant is it? as much as anyone else's. Peace. Gabe *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS
*Gabriel Roldán* Geospatial Developer On Thu, Feb 15, 2024 at 5:01 PM Andrea Aime < andrea.a...@geosolutionsgroup.com> wrote: > 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
