Thanks for the clarification.
case java.sql.Types.DECIMAL:
reuse.setField(resultSet.getBigDecimal(pos +
1).doubleValue(), pos);
break;
this causes both a nullpointer on null values as well as a double class
cast exception when serializing the tuple.
For th
On 23.03.2016 10:38, Chesnay Schepler wrote:
On 23.03.2016 10:04, Stefano Bortoli wrote:
I had a look at the JDBC input format, and it does indeed interpret
BIGDECIMAL and NUMERIC values as double.
This sounds more like a bug actually. Feel free to open a JIRA for this.
Actually, this was done
On 23.03.2016 10:04, Stefano Bortoli wrote:
I had a look at the JDBC input format, and it does indeed interpret
BIGDECIMAL and NUMERIC values as double.
This sounds more like a bug actually. Feel free to open a JIRA for this.
The status of the JDBCInputFormat is not adequate for real world use
I had a look at the JDBC input format, and it does indeed interpret
BIGDECIMAL and NUMERIC values as double. The status of the JDBCInputFormat
is not adequate for real world use case, as for example does not deal with
NULL values.
However, with little effort we fixed few stuff and now we are getti
The JDBC formats don't make any assumption as to what DB backend is used.
A JDBC float in general is returned as a double, since that was the
recommended mapping i found when i wrote the formats.
Is the INT returned as a double as well?
Note: The (runtime) output type is in no way connected t
Hi squirrels,
I working on a flink job connecting to a Oracle DB. I started from the JDBC
example for Derby, and used the TupleTypeInfo to configure the fields of
the tuple as it is read.
The record of the example has 2 INT, 1 FLOAT and 2 VARCHAR. Apparently,
using Oracle, all the numbers are rea
