The leading data integration platform for ETL / ELT data pipelines from APIs, databases & files to data warehouses, data lakes & data lakehouses. Both self-hosted and Cloud-hosted.
In the dbt type parsing logic for old normalization, empty string values for these 3 types are always converted to null for all destination types (L534, L558, L583).
In the 1s1t world, how should we handle this?
Each destination's try-cast logic decides if "" should be a typing error or null. ✅
Or, different destinations should handle this consistently (when technically possible). The protocol should define whether "" is valid, and enforce that on sources (fail CAT if they produce "") and destinations (fail DAT if they choke on "").
In the dbt type parsing logic for old normalization, empty string values for these 3 types are always converted to null for all destination types (L534, L558, L583).
In the 1s1t world, how should we handle this?