Comments (5)
the key difference is the format
, some programming languages doesn't have native support for 64 bit integers, that's why the service side has to accept it in string
format. The example that you have with maxResults
is limited to uint32
and 32 bit integers are a common thing in programming languages. Under the hood the services are defined using Protobuf, so that behavior and handling of data formats comes from that.
from nodejs-bigquery.
@alvarowolfx Got it, reading https://developers.google.com/discovery/v1/type-format a bit more and I see the reason why Uint64 is a string more clearly. Though from a TypeScript standpoint still seems strange, as I could pass a string "HEY THIS IS CRAZY"
to startIndex and would not get any type errors.
But to continue the discussion, when not using TypeScript, the module already works by passing in a literal integer.
Typescript can be very adaptable to support integers AND strings as a type definition. I would propose the issue is actually on the upstream https://github.com/callmehiphop/discovery-tsd/blob/master/src/converter.js
Personally for Typescript, I would convert the following schema to a number | string
:
"startIndex": {
"description": "Zero-based index of the starting row.",
"format": "uint64",
"location": "query",
"type": "string"
},
So if (schema.type === 'string' && (schema.format === 'uint64' || schema.format === 'int64'))
then string | number
I could propose in a PR on https://github.com/callmehiphop/discovery-tsd
Some background on my end, this issue arose when converting an existing project to use Typescript, and I was surprised by the definition.
from nodejs-bigquery.
The types.d.ts
file is auto generated from the BigQuery Discovery file. On the service side, the startIndex
field is declared as a string
with uint64
format.
from nodejs-bigquery.
Copying the comments from PR #1351
The Discovery document represents the backend/API definition, so it can only be changed by the service side itself. In this case, would be a change on the BigQuery backend.
What can be done is to change the generated code to take into consideration theformat
field of the Discovery doc, not just thetype
field. But in the end what the service side accepts is a string, so some conversion would have to happen.
Another thing to consider is that the startIndex attribute expects anuint64
and that can't be represented with a integer in Javascript, which holds at most2^53 - 1
. So users would have to use aBigInt
and convert tostring
anyway.
So in summary, it still makes sense to accept a string here because of the format, if we support number
, some conversion code would have to be added.
from nodejs-bigquery.
@alvarowolfx Oh I see. Seems like a mistake to me, especially because maxResults, though similar but oddly uint32, is defined as an integer.
From https://www.googleapis.com/discovery/v1/apis/bigquery/v2/rest
"maxResults":
{
"description": "Maximum number of results to read.",
"format": "uint32",
"location": "query",
"type": "integer"
},
On the Typescript side, would you agree it seems like a bug to have to adapt an integer index to be a string in order to pass through?
Obviously this is beyond an issue with this module, but not sure where the relevant upstream issue should be tracked.
from nodejs-bigquery.
Related Issues (20)
- BigQuery BigQuery/Model: "before all" hook for "should get a list of models" failed
- BigQuery BigQuery/Model: "after all" hook for "should extract a model" failed
- JSON not a valid type for parameterized query
- PartialFailureError loading from storage lib instead of this lib HOT 2
- Table extract to gcs and keep the kmsKeyName HOT 1
- Querying on authorized view HOT 4
- 📦 pack-n-play test: TypeScript code failed HOT 1
- Support for IAM conditions in TypeScript types HOT 1
- 7.5.0 is a breaking change HOT 4
- Use Template Strings for GoogleSQL raw queries HOT 1
- Please update documentation to indicate which function calls, or if this entire package uses, legacy APIs HOT 1
- Support for RANGE type
- Loading via write streams into Tables from Datasets with manually-specified project IDs returns invalid job
- Library cannot parse timestamp value "0" - Cannot convert a BigInt value to a number as PreciseDate HOT 7
- Direct usage of `queryParameters` broke with 7.6.0 HOT 6
- query result metadata problem HOT 3
- ApiError: Authentication unknown error HOT 4
- Warning: a recent release failed
- How to enable server certificate verification on the Nodejs BigQuery client for Mutual TLS ? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nodejs-bigquery.