fix(go/adbc/driver/flightsql): Parsing column metadata in FlightSQL driver#2481
Conversation
|
I will take a look. |
| suite.Equal(tt.xdbcIsNullable, xdbcIsNullables) // xdbcIsNullable | ||
|
|
||
| suite.Equal(tt.columnName, columnName, "columnName") | ||
| //suite.Equal(tt.ordinalPosition, ordinalPosition, "ordinalPosition") |
There was a problem hiding this comment.
why are we losing the ordinal positions for comparison?
There was a problem hiding this comment.
Good question. The ordinal position is set based on the order in which the columns are processed unless there's a metadata key ORDINAL_POSITION.
While writing the test I realized that even tho the schema is built always in the same order, the deserialization would (sometimes) cause columns to be in different order. I couldn't exactly understand the issue (if it even is an issue).
To work around this, I ignored the ordinal position (flight doesn't even set ORDINAL_POSITION) and appended the name of the columns being processed to every fields
There was a problem hiding this comment.
most likely the reason for that is because of the usage of a map. Golang maps do not have a guaranteed order and are in fact randomized when iterating. So you can't rely on the order of a map during iteration.
|
@davidhcoe any further comments on this? If not, I'm satisfied with merging this. |
|
Sorry, @zeroshade , I missed your question. I have it working on my end. All set to merge. |
3 participants
shared_utils.goXDBC_fields using fields metadataToXdbcDataTypefunction toshared_utils.goto resolve circular dependency issuesCOMMENT,CHARACTER_MAXIMUM_LENGTH,XDBC_SCALE,XDBC_PRECISION)*
COMMENT,CHARACTER_MAXIMUM_LENGTHseem to be snowflake specific even though it seems snowflake adbc driver has a separate implementation.XDBC_SCALE,XDBC_PRECISION