[
https://issues.apache.org/jira/browse/SQOOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14285111#comment-14285111
]
Jarek Jarcec Cecho commented on SQOOP-2027:
-------------------------------------------
Looking back, I would say that not requiring scale and precision for
{{Decimal}} is not the correct way. The problem is that {{Decimal(2, 3)}} is
different type then {{Decimal(3, 2)}} - hence I would agree that we should
require both parameters when creating the schema object. In terms of usage, as
we are not doing any math with decimals (+, -, /, *), but just transporting
them from source to destination I don't feel strongly about configuring the
{{MathContext}}. We could probably do that just to be sure if it don't have any
negative performance impact. We should still keep that information for schema
matching though.
> Sqoop2: SqoopIDFUtils handling of decimal need to be fixed
> ----------------------------------------------------------
>
> Key: SQOOP-2027
> URL: https://issues.apache.org/jira/browse/SQOOP-2027
> Project: Sqoop
> Issue Type: Bug
> Reporter: Veena Basavaraj
> Assignee: Veena Basavaraj
> Fix For: 1.99.5
>
>
> we need to handle scale and precision and make sure we instantiate the
> bigDecimal correctly
> We also need to make scale and precision mandatory to avoid confusion for
> connectors while they map their types
> {code}
> public class Decimal extends AbstractNumber {
> /**
> * Number of valid numbers.
> */
> private Long precision;
> /**
> * Number of decimal places.
> */
> private Long scale;
> {code}
> IDF java handling today is very lame!
> {code}
> public static Object toDecimal(String csvString, Column column) {
> return new BigDecimal(csvString);
> }
> {code}
> 3. there is no single unit test today with the values for precision and
> scale, so we need to define what those values are for Long
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
