Resolving type conversion errors

[ken0912]

When I try to import the string "1" into the int column of the database, I always get a type conversion error, which should be allowed.

[codecov[bot]]

Codecov Report

Attention: 11 lines in your changes are missing coverage. Please review.

Comparison is base (103f036) 71.28% compared to head (b442953) 71.12%.

Files	Patch %	Lines
bulkcopy.go	38.88%	11 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #790 +/- ## ========================================== - Coverage 71.28% 71.12% -0.17% ========================================== Files 24 24 Lines 5405 5416 +11 ========================================== - Hits 3853 3852 -1 - Misses 1305 1317 +12 Partials 247 247 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[denisenkom]

Why should this be allowed? Using strings instead of integers also creates ambiguity since string can contain a base 8 or base 16. For booleans it is even more complex, e.g should we allow True, true, 1. I don't think I would want to allow such ambiguity. It is easy enough to pass compatible and non ambiguous type.

[ken0912]

Why should this be allowed? Using strings instead of integers also creates ambiguity since string can contain a base 8 or base 16. For booleans it is even more complex, e.g should we allow True, true, 1. I don't think I would want to allow such ambiguity. It is easy enough to pass compatible and non ambiguous type.

I encountered this problem when dynamically importing data from csv to mssql, I just want to write a generalized tool to handle all the field type import cases, if all the imported tables are of varchar\nvarchar type, there is no problem, but if you want to import tables of a specified data type, such as int\float\bit, then you encounter a type conversion In fact, mssql native sql supports import. Sorry for the confusion, or do you have a better suggestion?

[denisenkom]

I am still not convinced that this is a good idea to have such conversion in the driver due to concerns I brought up initially: Using strings instead of integers also creates ambiguity since string can contain a base 8 or base 16. For booleans it is even more complex, e.g should we allow True, true, 1.

In your application you can query table metadata, determine column types and then perform conversion accordingly. That way you can resolve any ambiguity in conversion according to requirements of your application. Every application may have different approach in converting types, so pushing this logic into SQL driver would not be ideal.

[ken0912]

I am still not convinced that this is a good idea to have such conversion in the driver due to concerns I brought up initially: Using strings instead of integers also creates ambiguity since string can contain a base 8 or base 16. For booleans it is even more complex, e.g should we allow True, true, 1.

In your application you can query table metadata, determine column types and then perform conversion accordingly. That way you can resolve any ambiguity in conversion according to requirements of your application. Every application may have different approach in converting types, so pushing this logic into SQL driver would not be ideal.

Thank you for your reply!