feat: integrate jobs.query and stateless query for faster queries#1337
feat: integrate jobs.query and stateless query for faster queries#1337alvarowolfx merged 13 commits intogoogleapis:mainfrom
Conversation
feywind
left a comment
There was a problem hiding this comment.
Someone with more BQ experience should give this a look too, but I don't see major Node issues :)
| params: Query['params'], | ||
| types: Query['types'] | ||
| ): { | ||
| parameterMode: 'positional' | 'named' | undefined; |
There was a problem hiding this comment.
Might be good to pull this type out into an interface, but YMMV.
| const queryParameters: bigquery.IQueryParameter[] = []; | ||
| if (parameterMode === 'named') { | ||
| const namedParams = params as {[param: string]: any}; | ||
| for (const namedParameter in namedParams) { |
There was a problem hiding this comment.
Might want to use for (const namedParameter of Object.getOwnPropertyNames(namedParams)) or check each namedParameter against namedParams.hasOwnProperty().
| let rows: any = []; | ||
| if (res.schema && res.rows) { | ||
| rows = BigQuery.mergeSchemaWithRows_(res.schema, res.rows, { | ||
| wrapIntegers: options.wrapIntegers!, // TODO: fix default value |
There was a problem hiding this comment.
Same as above (re: not sure if this was moved from elsewhere or new code) but I wanted to ping in case the TODO isn't intentional.
| // The Job is important for the `queryAsStream_` method, so a new query | ||
| // isn't created each time results are polled for. | ||
| options = extend({job}, queryOpts, options); | ||
| if (options.timeoutMs) { |
There was a problem hiding this comment.
You can just delete, no need for the if.
| requestId: uuid.v4(), | ||
| jobCreationMode: 'JOB_CREATION_OPTIONAL', | ||
| }; | ||
| if (req.maxResults) { |
There was a problem hiding this comment.
gonna remove that
shollyman
left a comment
There was a problem hiding this comment.
Looks like reasonable coverage for the expansion here, thanks for putting it together.
feywind
left a comment
There was a problem hiding this comment.
All still looks fine. I wonder if we have a code style standard for foo_ vs _foo. Not really something specific to this PR.
|
Hey @alvarowolfx , thanks for contributing this! I tried using this out but noticed it seems like the types might be incorrect. In particular, when I use |
|
Also do you know if there is a reason jobTimeoutMs cannot be set? Seems like a nice safety net for runaway queries that is unavailable here (unless timeoutMs implicitly stops the query, but it doesn't seem like it) edit: Also timeoutMs doesn't seem to behave as I would expect. It seems like its a timeout for the initial request only, but then the option is deleted and it will wait for the results again still which may take much longer? I want to ensure my requests don't exceed 1s, but it seems like for a slow query it will still wait 10+s. The "job not complete" log fires fairly fast, but the results still don't resolve until the query actually finishes |
Integrate with
jobs.queryendpoint for faster small queries. Keep usingjobs.getQueryResultswhen pagination is needed. Fallback to current method of creating a job +jobs.getQueryResultswhen not possible to usejobs.query.