joshelser commented on a change in pull request #150:
URL: https://github.com/apache/calcite-avatica/pull/150#discussion_r696956278
##########
File path:
core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java
##########
@@ -722,13 +701,21 @@ protected Number getNumber() throws SQLException {
return (Number) super.getObject();
}
+ //FIXME There are several problems with this, the code below simply
implements
+ //a previous behaviour codified by the Calcite test suite.
+ //
+ // 1. It interprets a scale of 0 as a NOOP parameter, it should in fact
drop all fractionals
+ // 2. It uses RoundingMode.UNNECESSARY. All other Accessors use
RoundingMode.DOWN, and
+ // there is nothing in the specs that suggests that it should behave
differently
Review comment:
Having "UNNECESSARY" here makes me think that the expectation was that
BigDecimal would handle what was correct to do given the value and the scale
(letting something that involved changing data fly back to the user in the form
of an exception).
That said, I feel like ROUND_DOWN (truncating the extra decimal places) is
the reasonable thing to do.
##########
File path:
core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java
##########
@@ -722,13 +701,21 @@ protected Number getNumber() throws SQLException {
return (Number) super.getObject();
}
+ //FIXME There are several problems with this, the code below simply
implements
+ //a previous behaviour codified by the Calcite test suite.
+ //
+ // 1. It interprets a scale of 0 as a NOOP parameter, it should in fact
drop all fractionals
+ // 2. It uses RoundingMode.UNNECESSARY. All other Accessors use
RoundingMode.DOWN, and
+ // there is nothing in the specs that suggests that it should behave
differently
+ // 3. The scale from MetaData is NOT applied to BigDecimal values. Why ?
+ // 4. Metadata scale is only applied for getBigDecimal(), and only in this
Accessor. Why ?
Review comment:
One interesting thing I just noticed: `ResultSet#getBigDecimal(String,
int)` is actually deprecated. I'm wondering if this is just mimic'ing what some
other database once did, with the expectation that we eventually don't have to
worry about this in the future.
ResultSet seems to be wanting to just give you back a full-precision
BigDecimal if you ask for one (and let the caller handle the rest).
##########
File path:
core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java
##########
@@ -722,13 +701,21 @@ protected Number getNumber() throws SQLException {
return (Number) super.getObject();
}
+ //FIXME There are several problems with this, the code below simply
implements
+ //a previous behaviour codified by the Calcite test suite.
+ //
+ // 1. It interprets a scale of 0 as a NOOP parameter, it should in fact
drop all fractionals
+ // 2. It uses RoundingMode.UNNECESSARY. All other Accessors use
RoundingMode.DOWN, and
+ // there is nothing in the specs that suggests that it should behave
differently
+ // 3. The scale from MetaData is NOT applied to BigDecimal values. Why ?
+ // 4. Metadata scale is only applied for getBigDecimal(), and only in this
Accessor. Why ?
public BigDecimal getBigDecimal(int scale) throws SQLException {
Number n = getNumber();
if (n == null) {
return null;
}
BigDecimal decimal = AvaticaSite.toBigDecimal(n);
- if (0 != scale) {
+ if (0 != scale && !(n instanceof BigDecimal)) {
Review comment:
What's the thinking here? If we have a non-zero scale and it's not
already a big-decimal, we want to set the scale.
I was thinking of a case where we have a value `1234.1234` and we do a
`.getBigDecimal(<ordinal>, 2)` and we'd expect to get `1234.12`. Maybe this
scale isn't happening here, but down in the database itself?
I had tried removing this change and it doesn't seem to affect the new unit
test you added which is why I ask.
##########
File path:
core/src/main/java/org/apache/calcite/avatica/util/AbstractCursor.java
##########
@@ -722,13 +701,21 @@ protected Number getNumber() throws SQLException {
return (Number) super.getObject();
}
+ //FIXME There are several problems with this, the code below simply
implements
+ //a previous behaviour codified by the Calcite test suite.
+ //
+ // 1. It interprets a scale of 0 as a NOOP parameter, it should in fact
drop all fractionals
Review comment:
Agree. Not sure why, for a scale of 0 avatica does nothing.
Looking at https://docs.oracle.com/javadb/10.10.1.2/ref/rrefsqlj15260.html
it seems like at least this one database only considers valid scale to be a
minimum of 1. Maybe "0" is a special "do-nothing" case rather than truncate all
decimal places for JDBC? (granted, I'm coming up with that opinion based on
exactly one random website)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
