BQ API :: query vs insert ('query') job

1
votes

I'm looking at BQ API docs: https://cloud.google.com/bigquery/docs/reference/rest/v2/ and would like to confirm what's the difference between

Jobs: query POST https://www.googleapis.com/bigquery/v2/projects/projectId/queries

Jobs: insert (with a 'query' job) POST https://www.googleapis.com/bigquery/v2/projects/projectId/jobs

Both seem to be serving same purpose, querying a table with provided SQL statement...

Did I understand correctly that:

  • one return the query results (data) immediately in it's response body, (sort of synchronous / blocking process)
  • whereas other just creates a query job in the backend, (sort of async / non-blocking process) and later we still have to execute either Jobs: getQueryResults (if we got jobId) or Tabledata: list in order to fetch query results (data).. both of which I believe work in same way (sync / blocking) as Jobs: query?!

Thanks a lot!

Cheers!

1
google-bigquery
Yes, you have explained the difference correctly. Note that for most purposes, you probably want to use a client library, so you don't need to worry about the details of the REST API. – Elliott Brossard
Thanks! yeah was just confirming.. always good to know how things work underneath the hood ;). I posted another clarification re: Client Library as well stackoverflow.com/questions/51072806/… if you can clarify that as well pls.. Cheers! – Vibhor Jain
I'm not familiar with that change, but hopefully someone else can help. For this question, consider structuring it such that the "question" is how jobs.query and jobs.insert are different, then add an answer with an explanation (as you have already written). – Elliott Brossard
Hello, please can you provide the answer to your question as an answer? Thanks a lot – Christopher P

1 Answers

0
votes

so my understanding was correct:

Jobs: query POSTone return the query results (data) immediately in it's response body (sort of synchronous / blocking process)

Jobs: insert (with a 'query' job) POST just creates a query job in the backend, (sort of async / non-blocking process) and later we still have to execute either Jobs: getQueryResults (if we got jobId) or Tabledata: list in order to fetch query results (data).. both of which I believe work in same way (sync / blocking) as Jobs: query