[
https://issues.apache.org/jira/browse/SQOOP-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Fine updated SQOOP-2280:
--------------------------------
Fix Version/s: (was: 1.99.7)
1.99.8
> Sqoop2: Handle fixed point columns
> ----------------------------------
>
> Key: SQOOP-2280
> URL: https://issues.apache.org/jira/browse/SQOOP-2280
> Project: Sqoop
> Issue Type: Bug
> Components: sqoop2-framework
> Reporter: Abraham Elmahrek
> Fix For: 1.99.8
>
>
> From SQOOP-2213:
> {noformat}
> Great question. This is one I wasn't 100% sure about either unfortunately. I
> think it depends on what we want to expose to connector developers. I've
> assumed the connector developers want the framework to make sure the data is
> correct. This may not be right...
> Here's the different scenarios I see:
> 1. Object value is an integer.
> 2. Object value is a long.
> 3. Object value is a number, but neither a long nor integer.
> 4. Object value is not a number.
> The resulting code would be affected by the following variables:
> 1. How we want to handle Long values being passed to Integer sized columns
> 2. How we want to handle non-numeric values being passed
> This code will do the following:
> 1. Column(Integer), Value(Integer) => value as string
> 2. Column(Integer), Value(Long) => integer bits selected then transformed to
> string (e.g. Java.lang.Long.MAX_VALUE.intValue() should be -1).
> 3. Column(Integer), Value(String) => validate string is a number (perform #1
> or #2 casts) or throw an exception.
> 4. Column(Long), Value(Long) => value as string
> 5. Column(Long), Value(Integer) => value as string
> 6. Column(Long), Value(String) => validate string is a number (perform #4 or
> #5 casts) or throw an exception.
> I do see your point and this logic might be misplaced. Perhaps we can move
> this to a validation layer in due time.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
