Database Reference
In-Depth Information
the job. Instead, dry run requests will perform validation and authorization
checks to determine whether the job is likely to succeed, and then return
to the user without creating a persistent job or starting the work of the job.
Dry run requests may also return some statistics so that callers can estimate
the amount of resources that would be used by a job. This can be useful to
estimate the cost of running a job or to validate a query without actually
running it. The BigQuery web UI uses the dryRun flag to validate queries as
you type them, and you can use bq to do the same, as shown here:
$ bq query --dry_run --format=json "bad query"
Error in query string: Encountered " <ID> "bad "" at
line 1, column 1.
Was expecting:
<EOF>
Create Disposition
Create disposition controls when tables get created as the result of a job.
There are two values for createDisposition : CREATE_NEVER and
CREATE_IF_NEEDED . These values determine what BigQuery should do if
a table doesn't exist. CREATE_NEVER requires a pre-existing table for the
job to run. CREATE_IF_NEEDED is usually the default; it means that if a
table doesn't already exist, go ahead and create it, atomically, when the job
is ready to complete.
Write Disposition
The writeDisposition flag controls how and when to write to a table
and has three possible values: WRITE_APPEND , WRITE_TRUNCATE , and
WRITE_EMPTY .
If the write disposition is WRITE_APPEND , the job will append any new data
to the end of the table. You can run multiple jobs appending to a table in
parallel without worrying that they will interfere with each other or corrupt
the table.
If the write disposition is WRITE_EMPTY , if the table currently has data in
it, the write will fail. This can be useful to make sure that multiple jobs all
creating the same table don't end up appending their results together, if you
want only one of them to succeed.
Search WWH ::




Custom Search