Under the covers, the resources returned by synchronous jobs/query API and the follow-on jobs/getQueryResults API obscure most information found in the underlying jobs resource for the query job.
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.
Under the covers, the resources returned by synchronous
jobs/queryAPI and the follow-onjobs/getQueryResultsAPI obscure most information found in the underlyingjobsresource for the query job.I'm up against this issue while trying to implement
Client.list_jobs, which calls thejobs/listAPI 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 thedatasetIdof thedestinationTabledoes not match any of the "public" datasets for the project).Because of this discrepancy, I believe that the current
jobs.RunSyncQueryJobclass 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 ajobaccessor which created/returned ajobs.QueryJobinstance (which would be renamed from the currentjobs.RunAsyncQueryJob).Client.list_jobswould then always return instances ofjobs.QueryJob, even for synchronous queries.@dhermes, @jgeewax please comment if you disagree with this conclusion.