[Geoserver-devel] Rest Swagger Doc QA - Unimplemented parameters

[tbarsballe]

I am doing a QA pass on the current swagger docs for the rest API.

I have ran into a parameter that is documented, but does not appear to be implemented:

For /workspaces/{workspace}/coveragestores/{store}/{method}.{format} POST (coverage store file upload / granule harvest), the filename parameter appears in the docs, but does not show up anywhere in the code.
Looking at the old docs, this parameter is also documented there. Did this functionality get lost during the REST API upgrade? (Andrea - looks like you converted this endpoint?)

Torben

[tbarsballe]

Similarly, the granule delete endpoint (/workspaces/{workspace}/coveragestores/{store}/granules/{granuleId:.+}/{format}) has an optional format path variable that is declared in the code but never appears to be used, and is largely undocumented.

Torben

···

On Fri, Sep 15, 2017 at 3:24 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

I am doing a QA pass on the current swagger docs for the rest API.

I have ran into a parameter that is documented, but does not appear to be implemented:

For /workspaces/{workspace}/coveragestores/{store}/{method}.{format} POST (coverage store file upload / granule harvest), the filename parameter appears in the docs, but does not show up anywhere in the code.
Looking at the old docs, this parameter is also documented there. Did this functionality get lost during the REST API upgrade? (Andrea - looks like you converted this endpoint?)

Torben

[tbarsballe]

Found another parameter that is declared in the code, but never actually used: The “purge” parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

Torben

···

On Fri, Sep 15, 2017 at 5:06 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Similarly, the granule delete endpoint (/workspaces/{workspace}/coveragestores/{store}/granules/{granuleId:.+}/{format}) has an optional format path variable that is declared in the code but never appears to be used, and is largely undocumented.

Torben

On Fri, Sep 15, 2017 at 3:24 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

I am doing a QA pass on the current swagger docs for the rest API.

I have ran into a parameter that is documented, but does not appear to be implemented:

For /workspaces/{workspace}/coveragestores/{store}/{method}.{format} POST (coverage store file upload / granule harvest), the filename parameter appears in the docs, but does not show up anywhere in the code.
Looking at the old docs, this parameter is also documented there. Did this functionality get lost during the REST API upgrade? (Andrea - looks like you converted this endpoint?)

Torben

[tbarsballe]

For /workspaces/{workspace}/coveragestores/{store}/{method}.{format} POST
(coverage store file upload / granule harvest), the filename parameter
appears in the docs
<http://docs.geoserver.org/api/#/1.0.0/coveragestores.yaml&gt;, but does not
show up anywhere in the code.
Looking at the old docs
<Coverage stores — GeoServer 2.25.x User Manual,
this parameter is also documented there. Did this functionality get lost
during the REST API upgrade? (Andrea - looks like you converted this
endpoint?)

I located the handling of this parameter in

"AbstractStoreUploadController". Looks like the parameter was getting
manually pulled from the request. Modifying implementation to pass the
filename parameter in after retrieving it as a @RequestParam for
transparency.

Torben

[tbarsballe]

Similarly, the granule delete endpoint (/workspaces/{workspace}/cover
agestores/{store}/granules/{granuleId:.+}/{format}) has an optional
format path variable that is declared in the code but never appears to be
used, and is largely undocumented.

As far as i can determine, this structure is used to determine the output

format, and is included solely for compatibility with gsconfig.

[tbarsballe]

Found another parameter that is declared in the code, but never actually
used: The "purge" parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

As far as I can tell, this was blindly copied from the coveragestore

delete code, as I can find no purge parameter for datastore delete in the
old rest api.

For coveragestore, purge is used to delete the underlying files in addition
to the store; is this something that could be useful for datastore? I feel
like databases might make this a bit more complicated.

Torben

[Chris_Snider]

Hi,

If the datastore is JDBC, I think the purge makes sense to remove the underlying tables. I know we thought of a process for user defined layers, where users get to upload shapefiles that are ingested into the database as tables to specific schemas (PostgreSQL/PostGIS tables). When the layer is no longer required, removing them requires the GeoServer layer entries to be deleted, then a DB admin is required to manually drop the tables in the database. Having the PURGE on the REST call would make things, in our case, easier.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

(attachments)

···

Found another parameter that is declared in the code, but never actually used: The “purge” parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

As far as I can tell, this was blindly copied from the coveragestore delete code, as I can find no purge parameter for datastore delete in the old rest api.

For coveragestore, purge is used to delete the underlying files in addition to the store; is this something that could be useful for datastore? I feel like databases might make this a bit more complicated.

Torben

[tbarsballe]

Typically, individual tables become featureTypes, while the store represents the database (or schema) as a whole.

Since the purge parameter is currently only associated with stores, that would result in deleting the whole database, not just a table.
However, this suggests that adding a purge parameter to featureType delete may be useful in the case of database stores.

Torben

(attachments)

···

On Mon, Sep 18, 2017 at 3:48 PM, Chris Snider <chris.snider@anonymised.com> wrote:

Hi,

If the datastore is JDBC, I think the purge makes sense to remove the underlying tables. I know we thought of a process for user defined layers, where users get to upload shapefiles that are ingested into the database as tables to specific schemas (PostgreSQL/PostGIS tables). When the layer is no longer required, removing them requires the GeoServer layer entries to be deleted, then a DB admin is required to manually drop the tables in the database. Having the PURGE on the REST call would make things, in our case, easier.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

From: Torben Barsballe [mailto:tbarsballe@boundlessgeo.com]
Sent: Monday, September 18, 2017 4:01 PM
To: geoserver-devel <geoserver-devel@anonymised.comsourceforge.net>
Subject: Re: [Geoserver-devel] Rest Swagger Doc QA - Unimplemented parameters

Found another parameter that is declared in the code, but never actually used: The “purge” parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

As far as I can tell, this was blindly copied from the coveragestore delete code, as I can find no purge parameter for datastore delete in the old rest api.

For coveragestore, purge is used to delete the underlying files in addition to the store; is this something that could be useful for datastore? I feel like databases might make this a bit more complicated.

Torben

[Chris_Snider]

Torben,

I think the purge might be useful at both database, or more likely the schema level, as well as featureType levels. Definitely something that a GeoServer administrator would want to have locked down though J. Don’t want random removal of entire schemas from the database.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

(attachments)

···

Typically, individual tables become featureTypes, while the store represents the database (or schema) as a whole.

Since the purge parameter is currently only associated with stores, that would result in deleting the whole database, not just a table.

However, this suggests that adding a purge parameter to featureType delete may be useful in the case of database stores.

Torben

On Mon, Sep 18, 2017 at 3:48 PM, Chris Snider <chris.snider@…4594…> wrote:

Hi,

If the datastore is JDBC, I think the purge makes sense to remove the underlying tables. I know we thought of a process for user defined layers, where users get to upload shapefiles that are ingested into the database as tables to specific schemas (PostgreSQL/PostGIS tables). When the layer is no longer required, removing them requires the GeoServer layer entries to be deleted, then a DB admin is required to manually drop the tables in the database. Having the PURGE on the REST call would make things, in our case, easier.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

From: Torben Barsballe [mailto:tbarsballe@…3839…]
Sent: Monday, September 18, 2017 4:01 PM
To: geoserver-devel <geoserver-devel@lists.sourceforge.net>
Subject: Re: [Geoserver-devel] Rest Swagger Doc QA - Unimplemented parameters

Found another parameter that is declared in the code, but never actually used: The “purge” parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

As far as I can tell, this was blindly copied from the coveragestore delete code, as I can find no purge parameter for datastore delete in the old rest api.

For coveragestore, purge is used to delete the underlying files in addition to the store; is this something that could be useful for datastore? I feel like databases might make this a bit more complicated.

Torben

[tbarsballe]

Added the results of this discussion as a new JIRA issue here: https://osgeo-org.atlassian.net/browse/GEOS-8296

As for the docs, for now I’ll remove the unimplemented parameters.

Torben

(attachments)

···

On Mon, Sep 18, 2017 at 4:03 PM, Chris Snider <chris.snider@anonymised.com> wrote:

Torben,

I think the purge might be useful at both database, or more likely the schema level, as well as featureType levels. Definitely something that a GeoServer administrator would want to have locked down though J. Don’t want random removal of entire schemas from the database.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

From: Torben Barsballe [mailto:tbarsballe@boundlessgeo.com]
Sent: Monday, September 18, 2017 4:58 PM
To: Chris Snider <chris.snider@anonymised.com>
Cc: geoserver-devel <geoserver-devel@anonymised.comsourceforge.net>
Subject: Re: [Geoserver-devel] Rest Swagger Doc QA - Unimplemented parameters

Typically, individual tables become featureTypes, while the store represents the database (or schema) as a whole.

Since the purge parameter is currently only associated with stores, that would result in deleting the whole database, not just a table.

However, this suggests that adding a purge parameter to featureType delete may be useful in the case of database stores.

Torben

On Mon, Sep 18, 2017 at 3:48 PM, Chris Snider <chris.snider@anonymised.com4594…> wrote:

Hi,

If the datastore is JDBC, I think the purge makes sense to remove the underlying tables. I know we thought of a process for user defined layers, where users get to upload shapefiles that are ingested into the database as tables to specific schemas (PostgreSQL/PostGIS tables). When the layer is no longer required, removing them requires the GeoServer layer entries to be deleted, then a DB admin is required to manually drop the tables in the database. Having the PURGE on the REST call would make things, in our case, easier.

Chris Snider

Senior Software Engineer

Intelligent Software Solutions, A Polaris Alpha Company

From: Torben Barsballe [mailto:tbarsballe@boundlessgeo.com]
Sent: Monday, September 18, 2017 4:01 PM
To: geoserver-devel <geoserver-devel@anonymised.comsourceforge.net>
Subject: Re: [Geoserver-devel] Rest Swagger Doc QA - Unimplemented parameters

Found another parameter that is declared in the code, but never actually used: The “purge” parameter for datastore delete.

David - looks like you converted this endpoint, any comment?

As far as I can tell, this was blindly copied from the coveragestore delete code, as I can find no purge parameter for datastore delete in the old rest api.

For coveragestore, purge is used to delete the underlying files in addition to the store; is this something that could be useful for datastore? I feel like databases might make this a bit more complicated.

Torben