Destination Snowflake: break down ensureSchemaMatches #69117
+140
−73
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
branched from #69090
How
There are a few major hacks here:
getColumnsFromStreamactually parses out the "NOT NULL", becauseSnowflakeColumnUtils.columnsAndTypesreturns strings likeNUMBER(38,0) NOT NULL. Probably would be nicer to have columnsAndTypes return the new ColumnType struct directly, instead of destination-snowflake's bespokeColumnAndType- but that would be a lot of code churn right nowColumnDefinition, b/c it wasn't actually used anywhere. But now ColumnDefinition is identical to ColumnAndType (which, again, we probably should delete entirely)...SqlGenerator.alterTablemanually filters out nullable -> non-nullable changes, b/c destination-snowflake actually tries to respect field nullability, but this alteration feels likely to cause problems. I could be convinced to just do the blind alter though.TODO unit tests are probably completely broken
Can this PR be safely reverted and rolled back?