Snowflake Columns Mapping
- 2 Minutes to read
- Print
- DarkLight
- PDF
Snowflake Columns Mapping
- 2 Minutes to read
- Print
- DarkLight
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback!
Type Mapping
We match Snowflake data types to Rivery data types while extracting your data. If a data type is not supported, we will map it as a String type.
The following table shows the mapping of Snowflake data types to Rivery-compatible types:
| Rivery Type | Snowflake Type |
|---|---|
| STRING | STRING |
| INTEGER | NUMBER |
| FLOAT | FLOAT |
| BOOLEAN | BOOLEAN |
| TIMESTAMP | TIMESTAMP |
| TIMESTAMP | DATE |
| RECORD | VARIANT |
| VARIANT | VARIANT |
| OBJECT | VARIANT |
Scenarios of Data Type Conflicts
In instances where a datatype mismatch occurs, for example, when the datatype of an existing column in the source table is modified, the datatype of the corresponding column in the target table will be determined based on certain defined rules, thereby resolving the conflict. These rules ensure that the most comprehensive data type is chosen to maintain data integrity and avoid loss of information.
Examples of Data Type Conflicts
The table below outlines various scenarios of data type conflicts and the resolution rules. The Inferred Type column represents the chosen data type in the target table when there's a conflict.
| Conflicting Types | Inferred Type | Example Scenario |
|---|---|---|
| TIMESTAMP vs. DATE | TIMESTAMP | If a column in the source, initially of TIMESTAMP type, is changed to DATE, it will be converted into TIMESTAMP in the target. |
| SMALLINT vs. BOOLEAN | SMALLINT | A conflict between SMALLINT and BOOLEAN types in the source column will lead to the target column adopting the SMALLINT type. |
| INTEGER vs. (SMALLINT / BOOLEAN) | INTEGER | If an INTEGER is updated to SMALLINT or BOOLEAN in the source, it will be promoted to INTEGER in the target. |
| BIGINT vs. (INTEGER / SMALLINT / BOOLEAN) | BIGINT | If a column of BIGINT type is changed to SMALLINT, BOOLEAN, or INTEGER in the source, it will be elevated to BIGINT in the target. |
| DECIMAL vs. (INTEGER / BIGINT / SMALLINT / BOOLEAN) | DECIMAL | A column that is INTEGER or DECIMAL in the source will be transformed into DECIMAL. |
| DOUBLE PRECISION vs. (INTEGER / BIGINT / SMALLINT / BOOLEAN) | DOUBLE PRECISION | If there is a conflict between DOUBLE PRECISION and SMALLINT in the source column, the target column will adopt DOUBLE PRECISION. |
| REAL vs. (DOUBLE PRECISION / DECIMAL / INTEGER / BIGINT / SMALLINT / BOOLEAN) | REAL | If a column of DOUBLE PRECISION type is altered to REAL type in the source, it will remain as REAL in the target. |
| FLOAT vs. (INTEGER / BIGINT / SMALLINT / DECIMAL / REAL / DOUBLE PRECISION / BOOLEAN) | FLOAT | A source column initially of FLOAT type that is updated to INTEGER will remain as FLOAT in the target. |
| STRING vs. ALL DATATYPES | STRING | If a source column is initially set as STRING type and later changed to TIME or INTEGER, it will still be treated as STRING type in the target. |
| VARIANT vs. ALL DATATYPES | VARIANT | If a column in the source was VARIANT type and has been updated to INTEGER type, the target column will still retain the VARIANT type. |
Please Note:
VARCHAR and OBJECT have higher priority and will override other data types in conflicts.
Was this article helpful?