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
The BigQuery data types only has double-precision 64-bit integers and double-precision floating point values. In the BigQuery nomenclature, those types are referred to as INTEGER and FLOAT, however.
In the RichTableRow class containing implicit methods for TableRow, there are accessor methods to get field values from the row cast as JVM-world types, including: .getInt, .getLong, .getFloat, and .getDouble.
Since the BQ INTEGER corresponds to a Scala Long (not a Scala Int), and a BQ FLOAT corresponds to a Scala Double (not a Scala Float), something should be done to pre-empt confusion via precision mismatch or type casting errors.
Given Scio's general design to prefer choices in the direction of idiomatic Scala, it might make most sense to deprecate / get rid of .getFloat and .getInt.
The text was updated successfully, but these errors were encountered:
The BigQuery data types only has double-precision 64-bit integers and double-precision floating point values. In the BigQuery nomenclature, those types are referred to as INTEGER and FLOAT, however.
In the RichTableRow class containing implicit methods for TableRow, there are accessor methods to get field values from the row cast as JVM-world types, including:
.getInt
,.getLong
,.getFloat
, and.getDouble
.Since the BQ INTEGER corresponds to a Scala Long (not a Scala Int), and a BQ FLOAT corresponds to a Scala Double (not a Scala Float), something should be done to pre-empt confusion via precision mismatch or type casting errors.
Given Scio's general design to prefer choices in the direction of idiomatic Scala, it might make most sense to deprecate / get rid of
.getFloat
and.getInt
.The text was updated successfully, but these errors were encountered: