apache / apache/hop

[Bug]: reading an Oracle NUMBER(20,10) in 2.19 infers "Number" instead of "BigNumber" (as in 2.18)

Open
#8,303 0 comments 0 reactions 0 assignees View on GitHub
awaiting triage P2 Transforms
Dominant language
Java
Stars
1.5k
Forks
476
Avg merge
19h
Merged PRs (30d)
227

Description

### Apache Hop version?

2.19

### Java version?

OpenJDK 21

### Operating system

Windows

### What happened?

A column declared ``NUMBER(20,10)`` in an Oracle source database is read by a table-input transform.
In 2.18:
- the column is interpreted as ``BigNumber`` by the table-input and precision is kept
- Integer-conversion via select-values transform truncates the decimal part, even if the first decimal digit is >= 5

In 2.19:
- the column is interpreted as ``Number`` by the table-input, and some precision (last 3 digits) is lost
- Integer-conversion via select-values transform rounds up for first decimal digit is >= 5

[test-number.zip](https://github.com/user-attachments/files/32013792/test-number.zip)

### How to reproduce:

- in an Oracle DB, create and fill a table like:

```
create table EBI_TEST
(
ID integer,
ZOOM number(20,10)
);

insert into EBI_TEST values (4633913, 10.0770307123);
insert into EBI_TEST values (4565613, 0.5000007155);
insert into EBI_TEST values (5090200, 1234567890.0987654321);
commit;
```
- adapt the connection of the table-input of the attached to your setting/infrastracture

- run the pipeline in both 2.18 and 2.19

- compare the output by the write-to-log transform of the attached pipeline (especially the ``(!!!)`` marked lines in the note)

- 2.18: you see correctly "BigNumber" data type for ZOOM, no precision loss, and integer-conversion that truncates the decimal part
- 2.19: you (wrongly?) see "Number" data type for ZOOM, precision loss in the last 3 digits, and integer-conversion that partly rounds up

Image

Image

### Issue Priority

Priority: 2

### Issue Component

Component: Transforms

Contributor guide

Open the contributing guide

Research direction

Start by running the attached test-number.zip pipeline against Oracle on 2.19 and compare its table-input and select-values output with 2.18. Trace how the table-input transform handles Oracle NUMBER(20,10); done means ZOOM remains BigNumber without precision loss and integer conversion matches the 2.18 behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, sql
Domain
data, databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.