I am interested! And I've read the guidelines posted in one of the replies,
but I'm also not sure how useful this might be for the community in general,
at the moment (considering the replies meanwhile).
I have no doubt that if a rest api already exists and have a logic behind
each HTTP request,
On Fri, Feb 9, 2018 at 11:36 AM, Andrea Aime
wrote:
> Same goes for the update of attributes, it is not supported, but the
> underlying datastore API has optional support for it (same as above,
> database based datastore do support schema update).
>
Actually, I
Hi Ian,
what you say is very true, but a user may actually mean to delete the data.
An extra option added to the request to also drop the data contents
could be interesting, and there is optional support for it in the
underlying datastore API (various datastores do not implement it, but
database
Thanks for the answer! It is intended, then.
As REST can create a table, I thought there could be a way to do other
operations on it, other than inserts, updates, deletes, etc, on records. I
guess I wouldn't have searched for it if REST couldn't create tables.
Now it is only by curiosity: with a
In the same way that changes made via the REST API (or the GUI) don't
affect your shapefiles on the disk there is no reason for changes to the
GeoServer state to affect the tables in your database. In fact, I would be
very angry if on deleting a store in GeoServer my very expensive and hard
to
Hello..
When using REST API to create a new feature type via POST command, to a
given datastore properly set to postgres/postgis, geoserver successfully
creates the table. I pretend to update the attributes/table of objects and
do the corresponding update to postgis table. To do so, I use a PUT
Hello..
When using REST API to create a new feature type via POST command, to a
given datastore properly set to postgres/postgis, geoserver successfully
creates the table. I pretend to update the attributes/table of objects and
do the corresponding update to postgis table. To do so, I use a PUT