impl(bigquery): remove QueryReference in favor of QueryCreationMetadata - #6317
Conversation
There was a problem hiding this comment.
Code Review
This pull request refactors the BigQuery query API by removing the QueryReference enum and its associated query_reference() method. Instead, it introduces a metadata() method on the Query struct that returns a reference to QueryCreationMetadata, allowing direct access to fields like query_id and job_reference. All examples, tests, and internal usages have been updated to align with this simplified design. I have no additional feedback to provide as the changes are clean and idiomatic.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6317 +/- ##
==========================================
- Coverage 96.27% 96.26% -0.01%
==========================================
Files 283 282 -1
Lines 73333 73278 -55
==========================================
- Hits 70599 70541 -58
- Misses 2734 2737 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| if !metadata.query_id.is_empty() { | ||
| println!( | ||
| "Query was run in optional job mode. Query ID: \"{}\"", | ||
| metadata.query_id | ||
| ); | ||
| } | ||
| if let Some(job) = &metadata.job_reference { |
There was a problem hiding this comment.
comment: it is a tiny bit sad that the mutual exclusivity of these things is not encoded in the type. I think it's fine though.
There was a problem hiding this comment.
yeah, unfortunately was an error from the service side to not declared it nullable. It's a hard call to us to add an override to change the type, even that I would like to.
| let query_id = &metadata.query_id; | ||
| assert!(!query_id.is_empty(), "expected non-empty query_id"); |
There was a problem hiding this comment.
optional nit:
| let query_id = &metadata.query_id; | |
| assert!(!query_id.is_empty(), "expected non-empty query_id"); | |
| assert!(!metadata.query_id.is_empty(), "expected non-empty query_id"); |
Previously was assumed that QueryID and JobID were mutually exclusive (they're once, but now it isn't anymore). QueryReference was created with that in mind, so it doesn't make sense anymore and customers can access QueryID and JobID via QueryCreationMetadata now, giving access to the full RPC responses, without additional abstractions.
Towards #5844