Add sortables and collection search #7 #12
Conversation
| Implementers may choose to require fields in Item Properties to be prefixed with `properties.` or not, | ||
| or support use of both the prefixed and non-prefixed name, e.g., `properties.datetime` or `datetime`. |
There was a problem hiding this comment.
Higher-level question, is there any way to indicate whether a given client does "implicit prefixes" or not? I've found that, from the "client" perspective, it can be hard to know whether I should prefix with properties or not (pgstac just added support for both in December: https://github.com/stac-utils/pgstac/pull/329/files#diff-2274efb3ca918a5fdd73a71e90b8bbd97b180963ea131085df5aa0195455c5d6R129).
There was a problem hiding this comment.
No, not that I'm aware of, but wouldn't you express that in the property names?
Your properties may be either:
- properties.datetime
- properties.title
- ...
or:
- datetime
- title
- ...
The client should anyway only offer those that are in the list of properties, so it's pretty irrelevant whether they have prefixes or not.
There was a problem hiding this comment.
The client should anyway only offer those that are in the list of properties, so it's pretty irrelevant whether they have prefixes or not.
I guess this problem will be at least partially solved by sortables, since it will give services a way to say "please ask for sorting this way". Before sortables it was guess-and-check.
There was a problem hiding this comment.
Yeah, this is meant to be solved by sortables. For cases where sortables is not available, it's still as it was before. This PR is meant to be additive, not change any existing behaviour for APIs that did implement the previous version. I'd think this should be a separate PR then.
Co-authored-by: Pete Gadomski <[email protected]>
Related Issue(s): #7
Proposed Changes:
All changes are purely additive, no changes to existing implementations are required unless sortables are implemented.
PR Checklist: