René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Synchronous query API hides job","articleBody":"Under the covers, the resources returned by [synchronous `jobs/query` API](https://cloud.google.com/bigquery/docs/reference/v2/jobs/query) and the [follow-on `jobs/getQueryResults` API](https://cloud.google.com/bigquery/docs/reference/v2/jobs/getQueryResults) obscure most information found in the underlying [`jobs` resource](https://cloud.google.com/bigquery/docs/reference/v2/jobs#resource) for the query job.\n\nI'm up against this issue while trying to implement `Client.list_jobs`, which calls the [`jobs/list` API](https://cloud.google.com/bigquery/docs/reference/v2/jobs/list) 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).\n\nBecause 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.\n\n@dhermes, @jgeewax please comment if you disagree with this conclusion.\n","author":{"url":"https://github.com/tseaver","@type":"Person","name":"tseaver"},"datePublished":"2015-12-09T20:35:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1278/google-cloud-python/issues/1278"}