Database Reference
In-Depth Information
"projectId": "bigquery-e2e",
"datasetId":
"_0e32b38e1117b2fcea992287c138bd53acfff7cc",
"tableId":
"anon5c03da1f543a2486eca295f285b40eb87b01ea84"
},
"createDisposition": "CREATE_IF_NEEDED",
"writeDisposition": "WRITE_TRUNCATE"
}
},
"status": {
"state": "RUNNING"
},
"statistics": {
"creationTime": "1376685153301",
"startTime": "1376685153396"
}
Jobs.get()
After you create a job, it is common to poll until the job completes. (That is,
wait until job['status']['state'] == 'DONE' .) You should wait a
second or so between polling attempts, so your polling doesn't look like an
attempted denial-of-service attack on Google.
If you hadn't specified the job ID, you could still know how to look up
the job because the Jobs.insert() request returns the jobReference
in the response. However, if Jobs.insert() returned an error (say your
network was temporarily disabled), you'd have no way of knowing whether
the job actually ran.
If it sounds like we're over-hyping the value of providing your own job ID ,
it is because it is something that is easy to do that can solve a lot of potential
problems. We see a lot of support requests that are made more difficult by
not having a job ID to use to investigate, and a lot of customers that end up
accidentally rerunning jobs because they haven't provided a job ID. We just
want to make sure that you're aware of the option.
Here is a curl request that shows getting job state for the same
job_1394518034 previously created:
Search WWH ::




Custom Search