[
https://issues.apache.org/jira/browse/HIVE-13098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536835#comment-15536835
]
Sergey Shelukhin edited comment on HIVE-13098 at 9/30/16 7:41 PM:
------------------------------------------------------------------
Well, the crux of the matter is, whatever solution we do in Hive would be super
unwieldy code-wise, because decimals, decimal OIs, etc. are created in 1000000
places in giant static methods. I was going to add a global for compilation
(thread-local since that is single threaded) to be able to populate it
everywhere. At runtime (or during import) it can be used from the fields in
runtime objects (see DecimalUdf interface in the patch and its usage). That
would reduce the impact a lot compared to 700Kb of code changes...
Then we can choose what to do with the config once all the requisite code has
it.
The question is whether to do it at all, esp. since as Gopal noted other types
are also converted to null on overflow (unless they are bugged like
decimal-to-int cast ;)), so the proper fix that covers all the cases uniformly
would be very um, impactful in the codebase.
It is much easier to make the solution that requires user to actively
participate (e.g. trycast or functions to explore data), but it doesn't cover
the main case of the automated nullification.
was (Author: sershe):
Well, the crux of the matter is, whatever solution we do in Hive would be super
unwieldy code-wise, because decimals, decimal OIs, etc. are created in 1000000
places in giant static methods. I was going to add a global for compilation
(thread-local since that is single threaded) to be able to populate it
everywhere. At runtime (or during import) it can be used from the fields in
runtime objects (see DecimalUdf interface in the patch and its usage). That
would reduce the impact a lot compared to 700Kb of code changes...
Then we can choose what to do with the config once all the requisite code has
it.
The question is whether to do it at all, esp. since as Gopal noted other types
are also converted to null on overflow (unless they are bugged like
decimal-to-int cast ;)), so the proper fix that covers all the cases uniformly
would be very um, impactful in the codebase.
> Add a strict check for when the decimal gets converted to null due to
> insufficient width
> ----------------------------------------------------------------------------------------
>
> Key: HIVE-13098
> URL: https://issues.apache.org/jira/browse/HIVE-13098
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HIVE-13098.WIP.patch, HIVE-13098.WIP2.patch
>
>
> When e.g. 999999 is selected as decimal(5,0), the result is null. This can be
> problematic, esp. if the data is written to a table and lost without the user
> realizing it. There should be an option to error out in such cases instead;
> it should probably be on by default and the error message should instruct the
> user on how to disable it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
