allow to write queryables

[thomas-maschler]

Related Issue(s):

• Support to write to STAC APIs #241

Description:
Queryables are currently read-only. This PR adds two methods to the QueryablesMixin

• set_queryables
• write_queryables_to

The methods allow users to write queryables back to their API. For writing back to a REST endpoint the stac_io class used by the client will have to implement transactions and the API has to support updating queryables.

PR Checklist:

• Code is formatted
• Tests pass
• Changes are added to the CHANGELOG

[gadomski]

A couple of questions/issues:

• Unless I'm mistaken, this PR isn't enough to actually POST to urls becuase of this check:

  pystac-client/pystac_client/stac_api_io.py

  Lines 227 to 228 in 4a7bb2c

  	if _is_url(href):
  	raise APIError("Transactions not supported")

  . For full support, we'd need to add write-to-href support to StacApiIO as well I see you address this in your PR comment — how hard would it be to add a general transaction-enabled StacIO subclass to this PR?
• Is writing to queryables documented anywhere? I just re-read the filter extension text and didn't see any reference. I'm a bit hesitant to add functionality to pystac-client that isn't documented in the spec or an extension.

[thomas-maschler]

how hard would it be to add a general transaction-enabled StacIO subclass to this PR

This should be straight forward, but I think this is a PR of its own.

Is writing to queryables documented anywhere?

No, I also could not find any references. However, there needs to be away to update queryables, in particular since collection queryables may differ from catalog queryables. What is the best approach here? Make a PR to the filter extension and propose an optional POST/ PUT method for the queryables endpoint?

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 94.03%. Comparing base (21435b0) to head (45a9450).
Report is 68 commits behind head on main.

Files	Patch %	Lines
pystac_client/mixins.py	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #698      +/-   ##
==========================================
+ Coverage   93.43%   94.03%   +0.60%     
==========================================
  Files          13       13              
  Lines         990     1006      +16     
==========================================
+ Hits          925      946      +21     
+ Misses         65       60       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gadomski]

This should be straight forward, but I think this is a PR of its own.

Sounds good to me.

Make a PR to the filter extension and propose an optional POST/ PUT method for the queryables endpoint?

That would be my recommendation — if you're able to make one of the STAC community meetings (managed by this Google Group) to discuss the proposal that would help the idea get traction too. Have you seen this behavior used elsewhere in the community?

[thomas-maschler]

Ok, I will give it a shot. I haven't seen it elsewhere but am wondering how else people would determine what fields you can query in your collection.

For our use case, we index a standard set of fields. If a user wants to index other fields instead for their collection, updating the queryables endpoint will trigger reindexing of the collection

[gadomski]

If a user wants to index other fields instead for their collection, updating the queryables endpoint will trigger reindexing of the collection

After talking about it a bit with folks, I think that before adding this functionality, I'd want to first see this functionality defined in an extension (probably https://github.com/stac-api-extensions/transaction) and then advertised via a conformance class so that clients, including pystac-client, know that it's supported.

[thomas-maschler]

ok, I can work on that. I would have suggested to add it to the filter extension, since queryables are defined there.
The transaction extension only addresses updates to core objects. We can have a discussion on this during a community meeting

[gadomski]

Converting to draft until we've got an extension to reference.