[ADBA] Supporting BigInteger
Philippe Marschall
pm at netcetera.ch
Mon Dec 4 18:57:56 UTC 2017
On 04.12.17 19:21, Lance Andersen wrote:
> I went back and looked at some of the older JDBC EG archives. There was a brief discussion on BigInteger at that time but there was not a consensus on the mapping.
>
>
> Input welcome to seed the discussion :-)
Then I propose to allow mapping NUMBER(x, 0) to BigInteger in addition
to all the existing supported mappings of NUMBER(x, 0).
Two arguments can be made regarding the minimal supported value of x.
First, the minimal supported value should be 19 as smaller values can be
expressed with long.
Second the minimal supported value should be 1 as #getLong is also
supported for NUMBER(1, 0).
I'm siding with the second argument.
The existing integer types support various conversations. If these are
going to be ported from JDBC to ADBA then for consistency the following
should be considered:
BigInteger reading could also be allowed from columns who's data type
allows decimal places. This would be akin to supporting #getDate on a
TIMESTAMP column. The JDBC specification currently allows this.
BigInteger writing could also be allowed to columns who's data type
allows decimal places. This would be akin to supporting #setDate on a
TIMESTAMP column. The JDBC specification currently allows this.
As #getLong is supported for TINYINT, SMALLINT, INTEGER, BIGINT, REAL,
FLOAT, DOUBLE, DECIMAL, NUMERIC, BIT, BOOLEAN, CHAR, VARCHAR,
LONGVARCHAR supporting these conversions for BigInteger would be
consistent. I'm not found of many of those but if they're not revisited
for ADBA then the consistency argument has some weight. If they're not
revisited then I would welcome it if the conversion is defined stricter
(what values can be converted, what pattern is to be used for parsing,
what happens in case of a conversion error).
Cheers
Philippe
More information about the jdbc-spec-discuss
mailing list