Code improvements in SQLServerDataTable > 'internalAddRow()'#538
Code improvements in SQLServerDataTable > 'internalAddRow()'#538cheenamalhotra wants to merge 8 commits intomicrosoft:devfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #538 +/- ##
============================================
- Coverage 48.17% 48.06% -0.12%
+ Complexity 2585 2584 -1
============================================
Files 114 114
Lines 26578 26574 -4
Branches 4453 4445 -8
============================================
- Hits 12805 12772 -33
- Misses 11634 11677 +43
+ Partials 2139 2125 -14
Continue to review full report at Codecov.
|
|
Pretty much exactly what I was thinking for the linked issue. |
…boolean test for TVP.
|
Fix added for #539 - Support for Bit values (1,0) added for Boolean datatype in TVP. |
|
I think this introduces regressions, see my comment on #539 |
| switch (jdbcType) { | ||
| case BIGINT: | ||
| rowValues[pair.getKey()] = (val instanceof Number ? ((Number)val).longValue() : Long.parseLong(val.toString())); | ||
| rowValues[pair.getKey()] = (val instanceof Number ? (Long)val : Long.parseLong(val.toString())); |
There was a problem hiding this comment.
If val is an Integer this will throw a ClassCastException. Same for most of the instanceof checks below
|
I think this would benefit from some more tests, perhaps similar to the examples I gave on #539. As for the implementation, something like this is what I had in mind: And likewise for other types. Then call these from the jdbcType switch, eg: As a disclaimer I haven't tested this. |
|
Hi @alexnixon Thanks for your suggestions above. I agree to check for object instance for specific types for casting, but with this code, there are 2 downsides:
I am still investigating on changes, and will let you know if I find some gaps. Appreciate your involvements, looking forward to your comments. Since the PR is still in progress, we do want to make sure we cover all scenarios and don't break any existing support before merging this change. |
|
Thanks for the reply @cheenamalhotra Indeed it would break support for strings. If I was designing from scratch I would omit it, but I understand you might want to keep that for backwards compatibility. So I guess that's a choice for the project maintainer (which might be you?). But if it is to be included I would still argue for being strict, i.e. ensure it throws an exception for out-of-range values and decimals. I think the time/memory of an extra long conversion would be negligible, especially given we're about to write to a database, I just wrote the example code that way as it's shorter. |
| int nValueLen; | ||
| switch (jdbcType) { | ||
| case BIGINT: | ||
| rowValues[pair.getKey()] = (val instanceof Number ? (Long)val : Long.parseLong(val.toString())); |
There was a problem hiding this comment.
Should this really check for Number and then cast to Long? I would either change to instanceof Long or use ((Number)val).longValue() (which may introduce an unnecessary reboxing if val is Long)
1ff9ea2 to
3a7f7ae
Compare
Replaced with #990