fix: Add fallback to setObject(int, Object) for Number #812
Conversation
Why did you implement autoboxing-related changes? |
@vlsi Should I purge that commit? |
Codecov Report
@@ Coverage Diff @@
## master #812 +/- ##
===========================================
+ Coverage 65.27% 65.3% +0.02%
- Complexity 3520 3524 +4
===========================================
Files 166 166
Lines 15228 15232 +4
Branches 2466 2467 +1
===========================================
+ Hits 9940 9947 +7
+ Misses 4099 4098 -1
+ Partials 1189 1187 -2 Continue to review full report at Codecov.
|
I would love to see just those changes that are required, tested, etc. |
7aac037
to
ea71c42
@vlsi I've purged said commit. |
assertEquals(new BigDecimal("733"), rs.getBigDecimal(1)); | ||
pstruncate.execute(); | ||
|
||
// Test BigInteger |
vlsi
Apr 14, 2017
Member
Can you please split the test method to several ones and use relevant assert message? (see https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md#test )
Can you please split the test method to several ones and use relevant assert message? (see https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md#test )
RobertZenz
Apr 14, 2017
Author
Contributor
I've split it into three methods, though I'm not sure if the two fallback tests shouldn't be one.
I've split it into three methods, though I'm not sure if the two fallback tests shouldn't be one.
Add a fallback to the PgPreparedStatement.setObject(int, Object) method which handles Number types. This allows support for BigInteger and similar types (f.e. AtomicLong) which are not explicitly mentioned by JDBC. This fallback operates by invoking toString() on the Number, which is the same method used by setBigDecimal(int, BigDecimal). Also, setBigDecimal(int, BigDecimal) does now invoke setNumber(int, Number) because they work the same way. The tracking bug is #810.
ea71c42
to
1759c07
Is there something missing in the request or can this be pulled as is? |
Ping |
LGTM, barring any objections I'll merge this tomorrow |
Add a fallback to the PgPreparedStatement.setObject(int, Object) method which handles Number types. This allows support for BigInteger and similar types (f.e. AtomicLong) which are not explicitly mentioned by JDBC. This fallback operates by invoking toString() on the Number, which is the same method used by setBigDecimal(int, BigDecimal). Also, setBigDecimal(int, BigDecimal) does now invoke setNumber(int, Number) because they work the same way. The tracking bug is pgjdbc#810.
This pull request adds the fallback in question in #810.
It adds the following changes:
setNumber(int, Number)
method inPgPreparedStatement
with the same functionality assetBigDecimal(int, BigDecimal)
.setBigDecimal(int, BigDecimal)
does invokesetNumber(int, Number)
.setObject(int, Object)
for when aNumber
of an unknown/unhandled type is given.I've opted for the least intrusive way of adding this by simply adding another check "at the end" to see if the given
Object
is of the typeNumber
. If yes, it is forwarded tosetNumber(int, Number)
.