feat: expose reservation usage stats on jobs #524
Conversation
plamut
requested review from
a team and
stephaniewang526
and removed request for
a team
google-cla
bot
added
the
cla: yes
product-auto-label
bot
added
the
api: bigquery
There was a problem hiding this comment.
We need to add to https://github.com/googleapis/python-bigquery/blob/master/docs/reference.rst under "job-related types" too.
I know in most libraries we use automodule, but it probably makes sense to continue to have a central index for BigQuery, since we have a lot more modules than most.
| @@ -73,6 +74,16 @@ def _error_result_to_exception(error_result): | |||
| ) | |||
|
|
|||
|
|
|||
| ReservationUsage = namedtuple("ReservationUsage", "name slot_ms") | |||
There was a problem hiding this comment.
Interesting!
This is a little different from our usual "class with _properties dictionary" approach, but does seem to save us some boilerplate. I'll allow it. :-)
Do you think we should do this for our other read-only classes?
There was a problem hiding this comment.
I though a namedtuple would better communicate that it's a read-only (output-only) property, although our "_properties classes" can also have read-only properties - but yeah, a namedtuple requires much less boilerplate.
(FWIW, I personally view these output-only classes merely as named read-only containers with descriptive attribute names, and using a class with a bunch of read-only properties is just an implementation detail)
We can eventually refactor other output-only classes to namedtuples for consistency, yes, but I wouldn't do it just yet. There's not that much immediate value in it, as that code has already been written, and there might be some legit use cases out there that we don't know about... let's first wait and see how a namedtuple performs when released into the wild.
Closes #507.
This PR exposes reservation usage stats on job objects.
PR checklist: