You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It has become a known issue or design choice that the REST API returns numeric values either as numbers or strings, depending on multiple factors, and GraphQL API always returns numeric values as numbers. (Regarding the REST API, it will always return numeric values as strings if a pre-aggregation is used or if a measure is calculated.)
This makes it slightly inconvenient to handle numeric values at the data presentation layer, because it should both handle numbers and strings and properly cast them to desired types.
There's the castNumerics option in the JavaScript SDK that would cast all numeric values to numbers automatically, however, this might lead to precision loss since such a conversion would not be correct in case of numbers more than Number.MAX_SAFE_INTEGER or less than Number.MIN_SAFE_INTEGER as they can't be represented as JavaScript Number.
Describe the solution you'd like
Both REST API and GraphQL API should always return numeric values as strings so that the data presentation layer can parse and cast them consistently.
Potentially, these APIs can also return the native type (integer, float, or decimal) as part of the dataset or metadata, so that users who don't want to use castNumerics can use that information for the type conversion.
Describe alternatives you've considered
—
Additional context
Here's an example of how Cube currently works, as of v0.36.2.
Data model:
cubes:
- name: numericssql: > SELECT CAST(1.23 AS FLOAT64) AS value_float64, CAST(4.56 AS NUMERIC) AS value_numeric, CAST(789 AS INT64) AS value_int64, TRUE AS without_pre_aggregationdimensions:
- name: value_float64sql: value_float64type: number
- name: value_numericsql: value_numerictype: number
- name: value_int64sql: value_int64type: number
- name: without_pre_aggregationsql: without_pre_aggregationtype: booleanmeasures:
- name: max_float64sql: value_float64type: max
- name: max_numericsql: value_numerictype: max
- name: max_int64sql: value_int64type: max
- name: calculated_float64sql: "1.0 * {max_float64}"type: number
- name: calculated_numericsql: "1.0 * {max_numeric}"type: number
- name: calculated_int64sql: "1.0 * {max_int64}"type: numberpre_aggregations:
- name: maindimensions:
- value_float64
- value_numeric
- value_int64measures:
- max_float64
- max_numeric
- max_int64
Is your feature request related to a problem? Please describe.
It has become a known issue or design choice that the REST API returns numeric values either as numbers or strings, depending on multiple factors, and GraphQL API always returns numeric values as numbers. (Regarding the REST API, it will always return numeric values as strings if a pre-aggregation is used or if a measure is calculated.)
This makes it slightly inconvenient to handle numeric values at the data presentation layer, because it should both handle numbers and strings and properly cast them to desired types.
There's the
castNumerics
option in the JavaScript SDK that would cast all numeric values to numbers automatically, however, this might lead to precision loss since such a conversion would not be correct in case of numbers more thanNumber.MAX_SAFE_INTEGER
or less thanNumber.MIN_SAFE_INTEGER
as they can't be represented as JavaScriptNumber
.Describe the solution you'd like
Both REST API and GraphQL API should always return numeric values as strings so that the data presentation layer can parse and cast them consistently.
Potentially, these APIs can also return the native type (integer, float, or decimal) as part of the dataset or metadata, so that users who don't want to use
castNumerics
can use that information for the type conversion.Describe alternatives you've considered
—
Additional context
Here's an example of how Cube currently works, as of v0.36.2.
Data model:
Example query:
REST API, query that does not use a pre-aggregation:
REST API, query that uses a pre-aggregation:
GraphQL API, any query:
The text was updated successfully, but these errors were encountered: