On Tue, Feb 20, 2024 at 2:52 PM Andrea Aime <
andrea.a...@geosolutionsgroup.com> wrote:
> If one uploads in replace mode, a lot of damage can be done... the old
> data is removed before adding the new one.
> All one needs is to upload a file that can be self described properly, but
> cannot be pro
On Fri, Feb 16, 2024 at 3:27 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:
> Believe me I absolutely understand the convenience of just adding a
> parameter to the existing delete featuretype api. Heck, we would have saved
> all the time invested in this discussion an my customers woul
Hi Andrea,
Thanks for this valuable break down.
Everything you mention makes sense, and I think we're getting to the root
of our disagreement.
Believe me I absolutely understand the convenience of just adding a
parameter to the existing delete featuretype api. Heck, we would have saved
all the ti
Ok,
let's start over with more context. In particular, let's start with the
existing API and how it works in terms of "native" resources, and what
"dangerous" functionality is already there.
*List of native resources*
How does one get a list of resources (feature types, coverages, wms and
wmts lay
Cécile,
My customers would find this concept useful, and I would support you in
making a proposal.
I like the idea of making a new REST API endpoint to avoid overlap and
accidental use. Also gives an opportunity for and admin setting to disable
for those inclined.
--
Jody Garnett
On Mon, Feb 12
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?
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 ha
s
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 th
On Thu, Feb 15, 2024 at 3:00 PM Gabriel Roldan
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 hard
Hi,
Good points, Gabriel.
I support having a little more explicit end-points for the different operations.
Regards,
Roar Brænden
> 15. feb. 2024 kl. 15:00 skrev Gabriel Roldan :
>
>
>
> * Flag parameters are bad design, increases complexity and understanding,
> breaks a couple principles.
>
>
> * 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 b
dmins.
>>> If we will have a configuration option "cascade=true" then it should be
>>> off by default, and somehow the geoserver admin who turns it on should be
>>> made aware of all the consequences.
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>
ult, and somehow the geoserver admin who turns it on should be
>> made aware of all the consequences.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>>
>>
>> *Lähettäjä:* Roar Brænden
>> *Lähetetty:* keskiviikko 14. helmikuuta 2024 23.29
>&
t, and somehow the geoserver admin who turns it on should be
>> made aware of all the consequences.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>>
>>
>> *Lähettäjä:* Roar Brænden
>> *Lähetetty:* keskiviikko 14. helmikuuta 2024 23.29
EST? Both are secured only by the
> username/password. However, I do not know if it is possible to drop
> database tables from the UI. I have seen some user requests about cascading
> deletes so that deleting a layer would also delete the data. I think that
> is not a good idea.
>
>
&
keskiviikko 14. helmikuuta 2024 17.46
Vastaanottaja: Jody Garnett
mailto:jody.garn...@gmail.com>>
Kopio:
geoserver-users@lists.sourceforge.net<mailto:geoserver-users@lists.sourceforge.net>
Aihe: Re: [Geoserver-users] Deleting database table through REST API
Hi all,
For the record,
I&#
iviikko 14. helmikuuta 2024 17.46
> Vastaanottaja: Jody Garnett
> Kopio: geoserver-users@lists.sourceforge.net
> Aihe: Re: [Geoserver-users] Deleting database table through REST API
>
> Hi all,
> For the record,
> I'm utterly against deleting database tables through the
database table through REST API
Hi all,
For the record,
I'm utterly against deleting database tables through the geoserver REST API
* It's absolutely dangerous
* The REST API shall with GeoServer "resources", not infrastructure ones
If I wanted to delete a table through *a* REST API
Hi all,
For the record,
I'm utterly against deleting database tables through the geoserver REST API
* It's absolutely dangerous
* The REST API shall with GeoServer "resources", not infrastructure ones
If I wanted to delete a table through *a* REST API, I'd better run two
queries, one to delete the
I am open to improvements and addition to the importer API (which offers
some control as it is responsible for the automatic creation of tables; it
has an opportunity to delete an existing table when replacing contents).
See example
https://docs.geoserver.org/latest/en/user/extensions/importer/res
Hi Cécile,
I don't see the feature being implemented in the code.
The wiki page you're looking for is this one:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-fixes,-improvements-and-new-features-in-GeoServer
Cheers
Andrea
On Mon, Feb 12, 2024 at 10:39 AM Cé
Hi all
When creating a feature type in a database datastore with the REST API,
GeoServer will create the corresponding table if it does not exist.
We were wondering if similarly the deletion of a table was also possible
when deleting the associated feature type and I found this discussion:
http
22 matches
Mail list logo
