[
https://issues.apache.org/jira/browse/SQOOP-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408059#comment-16408059
]
Hudson commented on SQOOP-2976:
-------------------------------
SUCCESS: Integrated in Jenkins build Sqoop-hadoop200 #1151 (See
[https://builds.apache.org/job/Sqoop-hadoop200/1151/])
SQOOP-3293: Document SQOOP-2976 (vasas:
[https://git-wip-us.apache.org/repos/asf?p=sqoop.git&a=commit&h=d57f9fb06b55650adc75cd1972df0024d7e4dba1])
* (edit) src/docs/user/import.txt
* (edit) COMPILING.txt
> Flag to expand decimal values to fit AVRO schema
> ------------------------------------------------
>
> Key: SQOOP-2976
> URL: https://issues.apache.org/jira/browse/SQOOP-2976
> Project: Sqoop
> Issue Type: Improvement
> Affects Versions: 1.4.6
> Reporter: Thomas Scott
> Assignee: Fero Szabo
> Priority: Major
> Fix For: 1.5.0
>
> Attachments: SQOOP-2976.patch, SQOOP-2976.patch
>
>
> As per https://issues.apache.org/jira/browse/AVRO-1864 when importing from
> Oracle (or any other database that truncates decimals) Sqoop jobs can fail
> because the scale of the decimal produced by the database does not match the
> scale in the AVRO file.
> For instance if the value 3.15 is produced by Oracle and the AVRO decimal
> scale is 3 (this can happen even if the Oracle column is defined with scale
> of 3) then the job will fail.
> Can we have a flag (--pad-decimals) that pads incoming values with zeros to
> fit the AVRO schema (e.g. 3.15 becomes 3.150).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
