-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce APIs for list_recordings and update_metadata #8223
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
7ab5f43
to
711a372
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I agree that we should spend just a bit of time thinking about the next level of improvements for all the APIs
.map(|tc| tc.try_to_arrow_record_batch()) | ||
.collect(); | ||
|
||
// TODO(jleibs): surfacing this schema is awkward. This should be more explicit in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we expose schema as top level field for get/list metadata, even though it's in the transport chunk?
I guess for the Query (i.e. data API) we should (as initially discussed) strive to go the opposite way and only include the schema in the first message of the stream?
Related
What