SEPURI-SAI-KRISHNA opened a new issue, #12908: URL: https://github.com/apache/seatunnel/issues/12908
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened The ORC sink writes `NULL` instead of the value when a `DECIMAL` does not fit the target column. The row is written, the job succeeds, and there is no exception, no warning and no log line. `OrcWriteStrategy.java:352` converts the value in one unchecked call: ```java if (value instanceof BigDecimal) { decimalColumnVector.set(row, HiveDecimal.create((BigDecimal) value)); } ``` Both halves of that return `null` rather than reporting a problem: 1. `HiveDecimal.create(BigDecimal)` returns `null` above ORC's maximum precision of 38. 2. `DecimalColumnVector.set` internally calls `enforcePrecisionScale`, which returns `null` when the value does not fit the precision and scale the column actually **declares**. Neither result is checked, and `set(row, null)` simply marks the cell null. ### Measured on `dev` Writing one row through `OrcWriteStrategy` and reading it back through `OrcReadStrategy`: | value written | declared column | read back | | --- | --- | --- | | `123.45` | `decimal(10,2)` | `123.45` | | `123456789012345678901234567890123456789` (39 digits) | `decimal(38,0)` | **`null`** | | `12345678901234` (14 digits) | `decimal(10,2)` | **`null`** | **The third row is the reachable one.** It is not a hand-written `decimal(38,0)`; it is a value merely wider than the column it was declared with, which arises from a narrow or inferred JDBC precision, a sampled schema, a schema-less source, or a SQL transform that multiplies decimals. ### The Parquet sink in the same module refuses this loudly Given the same two inputs, `ParquetWriteStrategy` throws both times: ``` 39 digits into decimal(38,0): AvroTypeException: Cannot encode decimal with precision 39 as max precision 38 12345678901234 into decimal(10,2): AvroTypeException: Cannot encode decimal with precision 16 as max precision 10. This is after safely adjusting scale from 0 to required 2 ``` So two sinks in one module disagree about whether losing a value silently is acceptable. ### Why no test catches it `OrcWriteStrategyTest` has no decimal coverage at all today, so nothing compares a round-tripped decimal against what was written. ### What you expected to happen A value the target column cannot represent should fail the write, naming the value and the column, as the Parquet sink already does. Silently substituting `NULL` turns a type problem into undetected data loss. ### SeaTunnel Version `dev` (verified against the live file at `?ref=dev`; the line is unchanged). ### Note A declared precision above 38 is already rejected when the schema is built, so this issue is about VALUES, not DECLARATIONS. Closed #10820 ("ORC File Source corrupts BINARY type data") is a useful precedent: the same class of silent ORC corruption, accepted and fixed. ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
