[Bug]: reading an Oracle NUMBER(20,10) in 2.19 infers "Number" instead of "BigNumber" (as in 2.18)
- 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
### Issue Priority
Priority: 2
### Issue Component
Component: Transforms
Contributor 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