[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