-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: return extra args when autoPaginate is on #1365
fix: return extra args when autoPaginate is on #1365
Conversation
needs fix from googleapis/nodejs-paginator#365 |
src/bigquery.ts
Outdated
export type QueryResultsResponse = bigquery.IGetQueryResultsResponse & | ||
bigquery.IQueryResponse; | ||
|
||
export type QueryRowsResponse = PagedResponse< | ||
RowMetadata, | ||
Query, | ||
bigquery.IGetQueryResultsResponse | ||
QueryResultsResponse | ||
>; | ||
export type QueryRowsCallback = PagedCallback< | ||
RowMetadata, | ||
Query, | ||
bigquery.IGetQueryResultsResponse | ||
QueryResultsResponse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leahecole do you think this is a breaking change ? I feel like is fine because it still compatible with the previous type, I'm just enhancing to cover other response types when getting query results, which can come as IGetQueryResultsResponse
(normal path with jobs.getQueryResults
) or IQueryResponse
(jobs.query
"fast query path).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooo this is such a good question. I thought about it for a bit and I think you're right - it is backwards compatible - I think it does merit a minor release and not just a patch release though because you are adding functionality - you're just doing so in a way that is backwards compatible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is okay from a TS perspective - left one comment, but would love a BQ review too
src/bigquery.ts
Outdated
export type QueryResultsResponse = bigquery.IGetQueryResultsResponse & | ||
bigquery.IQueryResponse; | ||
|
||
export type QueryRowsResponse = PagedResponse< | ||
RowMetadata, | ||
Query, | ||
bigquery.IGetQueryResultsResponse | ||
QueryResultsResponse | ||
>; | ||
export type QueryRowsCallback = PagedCallback< | ||
RowMetadata, | ||
Query, | ||
bigquery.IGetQueryResultsResponse | ||
QueryResultsResponse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooo this is such a good question. I thought about it for a bit and I think you're right - it is backwards compatible - I think it does merit a minor release and not just a patch release though because you are adding functionality - you're just doing so in a way that is backwards compatible.
src/bigquery.ts
Outdated
query( | ||
query: Query, | ||
options?: QueryOptions | ||
): Promise<SimpleQueryRowsResponse> | Promise<QueryRowsResponse>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to also update the docstring to have an example of this? Or is it going to be the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this signature change as was not needed. So I think we don't need updates to the docstring, this is just to fix a behavior that users were already expecting from that method.
src/bigquery.ts
Outdated
@@ -80,15 +80,18 @@ export type PagedRequest<P> = P & { | |||
maxApiCalls?: number; | |||
}; | |||
|
|||
export type QueryResultsResponse = bigquery.IGetQueryResultsResponse & |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this syntax feels absolutely wild to me, a concrete type made from ANDing two interfaces? Should it be IQueryResultsResponse?
Does this blow up if you have fields with equal names but varying types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to be an or
, so it's more accurate. When using the .query
method, the return can be either a IQueryResultsResponse
or IQueryResponse
, this way all common fields are gonna be in that type by default and if you need an specific type, you can create a type coercion like I show in the system-tests:
nodejs-bigquery/system-test/bigquery.ts
Line 346 in bef5262
it('should query with jobs.query and return all PagedResponse as positional parameters', async () => { nodejs-bigquery/system-test/bigquery.ts
Line 357 in bef5262
it('should query without jobs.query and return all PagedResponse as positional parameters', async () => {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"this syntax feels absolutely wild to me" that's because it is - you can do some wild and wacky things with typescript 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re Alvaro, I think the OR is probably a better choice
Fixes #1210
Fixes #1362