allow to write queryables

[thomas-maschler]

Related Issue(s):

• 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:

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

[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 :warning:

Additional details and impacted files

```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: 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.