[
https://issues.apache.org/jira/browse/SQOOP-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274146#comment-14274146
]
Veena Basavaraj commented on SQOOP-1987:
----------------------------------------
I fail to understand the overall strategy/goal for matching data, currently it
seems to be based on "schema" provides in the from and the to IDF. the current
ticket proposes to match based on the data in.
Which one takes precedence over the other [~jerrychenhf]
> Sqoop2: Add a NullMatcher
> -------------------------
>
> Key: SQOOP-1987
> URL: https://issues.apache.org/jira/browse/SQOOP-1987
> Project: Sqoop
> Issue Type: Sub-task
> Affects Versions: 1.99.5
> Reporter: Qian Xu
> Assignee: Qian Xu
> Priority: Minor
> Fix For: 2.0.0
>
>
> The {{MatcherFactory}} will create a suitable matcher according to toSchema
> and fromSchema conditions.
> If {{NameMatcher}} is chosen, it means FROM and TO schema should not be
> empty, so the following code is not necessary. Thanks [~jerrychenhf] for
> pointing it out.
> {code}
> public Object[] getMatchingData(Object[] fields) {
> if (getToSchema().isEmpty()) {
> // No destination schema found. No need to convert anything.
> return fields;
> }
> {code}
> If {{LocationMatcher}} is chosen, TO schema can be empty. In code there is a
> rule 0. If TO schema is empty, it will not convert anything.
> {code}
> public Object[] getMatchingData(Object[] fields) {
> if (getToSchema().isEmpty()) {
> // No destination schema found. No need to convert anything.
> return fields;
> }
> {code}
> I'm thinking we can create a third matcher {{NullMatcher}}, which simply
> return input fields as result. This is a tiny optimization thing.
> Second, it'd be better to have precondition check in constructor of both
> matcher classes. So that we know better that when the matcher should be used.
> And related test cases should be updated, if precondition check is added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
