Cache job constructed for a synchronous query.

[tseaver]

Fixes #1673.

[dhermes]

Code itself LGTM but before merging here is a design question: should the user have a way to bust our cached value?

[tseaver]

Should the user have a way to bust our cached value?

I wouldn't think so. The QueryJob instance has no "interesting" user-settable state once the job is running: its only use is to poll for status / statistics, etc.

[dhermes]

But what if the job attribute becomes out of sync with the actual job? Is it even possible? What if the job on the server ceases to exist but the property still is valid locally?

[tseaver]

But what if the job attribute becomes out of sync with the actual job? Is it even possible?

That is what the job.reload() call is for (when polling the status).

What if the job on the server ceases to exist but the property still is valid locally?

No different than holding onto any other client-side proxy for a server-side resource. The docs for jobs.query say:

The query results from this method are saved to a temporary table that is deleted approximately 24 hours after the query is run.

which implies that the job must last that long, too (since its ID is used to fetch the results). If the user tries to fetch results after the job / result table is gone, then the API will (presumably) raise a 404.

[dhermes]

LGTM