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

Reply via email to