PDA

View Full Version : Problem in Database.java - Math.round()



kettle_grudman
03-22-2006, 11:59 PM
There seems to be a problem using the Math.round() method. Here's how to replicate ...

CREATE TABLE `source_testing` (
`glb_dtime` bigint(16) unsigned NOT NULL default '0',
`description` varchar(45) default NULL,
PRIMARY KEY (`glb_dtime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1


CREATE TABLE `stage_testing` (
`glb_dtime` bigint(16) unsigned NOT NULL default '0',
`description` varchar(45) default NULL,
PRIMARY KEY (`glb_dtime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1


insert into `source_testing`
values (
4522787498623415, NULL
)


Use a simple transformation, table input -> table output. The target table is populated but with the following value ...
4522787498623416

problem seems to lie here in be\ibridge\kettle\core\database\Database.java line 514

>
> ps.setLong(pos, Math.round( v.getNumber() ) );
>

Changing the code to the following yields the correct value in the target table, however I'm sure this is far from being a desirable solution.

>
> Double val = new Double(v.getNumber());
> ps.setLong(pos, val.longValue() );
>


My version of java ...
java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

kettle_grudman
03-23-2006, 12:42 AM
Hi Matt,

Thanks for the quick response.

>
> I guess the precision of the 4522787498623415
> figure is too big for Number to hold.
>
values larger than 4522787498623415 are inserted correctly, e.g. 4522787498623518, however there are others which fail, e.g. 4522787498623515 - 4522787498623517. Your suggestion of using Select Values with the meta-data change works as expected, so I guess not an issue.

>
> What database table are you reading from?
>
I first noticed the problem when pulling data from an Oracle database and started testing this issue on a MySQL database. Occurs in both.

>
> Try to place a Select Values step in between with
> a meta-data change to BigDecimal.
>
works like a charm - thanks

Regards,

Greg

kettle_grudman
03-23-2006, 12:45 AM
oops, seems I edited your response? Sorry.

MattCasters
03-23-2006, 12:52 AM
Well, the reason I asked about the databases used, is that beyond a certain precision, BigNumber (java BigDecimal) is and should be used to represent the data.

For Oracle this should be anything over Number(9,x). (Have to check)

So I will be using your example to test a couple of things, maybe we should switch to BigDecimal earlier.

Hey, thanks for the feedback!

Matt