You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm up against this issue while trying to implement Client.list_jobs, which calls the jobs/list API and tries to return instances of the appropriate job class. That API call returns job resources for synchronous queries which are effectively indistinguishable from those created for asynchronous queries (I've only been able to tell them apart by checking that the datasetId of the destinationTable does not match any of the "public" datasets for the project).
Because of this discrepancy, I believe that the current jobs.RunSyncQueryJob class is misnamed: instead, it should be called something like query.QueryResults: this new/renamed class would not pretend to be a job, but instead would have a job accessor which created/returned a jobs.QueryJob instance (which would be renamed from the current jobs.RunAsyncQueryJob). Client.list_jobs would then always return instances of jobs.QueryJob, even for synchronous queries.
@dhermes, @jgeewax please comment if you disagree with this conclusion.
The text was updated successfully, but these errors were encountered:
Under the covers, the resources returned by synchronous
jobs/query
API and the follow-onjobs/getQueryResults
API obscure most information found in the underlyingjobs
resource for the query job.I'm up against this issue while trying to implement
Client.list_jobs
, which calls thejobs/list
API and tries to return instances of the appropriate job class. That API call returns job resources for synchronous queries which are effectively indistinguishable from those created for asynchronous queries (I've only been able to tell them apart by checking that thedatasetId
of thedestinationTable
does not match any of the "public" datasets for the project).Because of this discrepancy, I believe that the current
jobs.RunSyncQueryJob
class is misnamed: instead, it should be called something likequery.QueryResults
: this new/renamed class would not pretend to be a job, but instead would have ajob
accessor which created/returned ajobs.QueryJob
instance (which would be renamed from the currentjobs.RunAsyncQueryJob
).Client.list_jobs
would then always return instances ofjobs.QueryJob
, even for synchronous queries.@dhermes, @jgeewax please comment if you disagree with this conclusion.
The text was updated successfully, but these errors were encountered: