Dan Allan
Dan Allan
Superseded by #719
Interesting arguments that JMESPath is the more robust choice: https://github.com/OAI/OpenAPI-Specification/discussions/2556#discussioncomment-678802
I think JMESPath is the clear winner. Closing, but open to arguments if anyone wants to revive this in the future.
Postgres implements JSONPath, and it looks like SQLite followed suit. If we want predicate push-down, that is the language we will need. However, the points raised in the linked post...
As of September it looks like JSONPath is on track to be formally specified. https://datatracker.ietf.org/wg/jsonpath/about/
The RFC is dormant, but there is nonetheless an actively maintained Python implementation of the proposal. https://pypi.org/project/jsonpath-ng/ For use cases where we want to fish just a couple fields (e.g....
Latest thinking on this, per chat with @pbeaucage: - Deprecate `select_metadata` and our support JMESPath, as JMESPath does too much: too complicated, and maybe exposes too much power to clients...
I like that suggestion very well, and I like the name `part`. In the future (months away) I hazily foresee enabling Tiled to track multiple versions of data: - replicas...
I also like that giving a distinct name to this concept helps clarify which abstraction level you are operating at. Referring to a `part` moves you from (1) to (2)...
Rebased on `main` after merging #661. The renaming of `data_source` to `part`, in the places discussed has been done. The to-dos... > Implement `read()` on `UnionClient` (i.e. `c['x']`) itself, which...