[
https://issues.apache.org/jira/browse/SQOOP-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145336#comment-16145336
]
Markus Kemper commented on SQOOP-3066:
--------------------------------------
The option added for this is: \-\-oracle-escaping-disabled true|false
> Introduce an option + env variable to enable/disable SQOOP-2737 feature
> -----------------------------------------------------------------------
>
> Key: SQOOP-3066
> URL: https://issues.apache.org/jira/browse/SQOOP-3066
> Project: Sqoop
> Issue Type: Improvement
> Affects Versions: 1.4.6
> Reporter: Attila Szabo
> Assignee: Attila Szabo
> Priority: Critical
> Fix For: 1.4.7
>
> Attachments: SQOOP-3066.patch
>
>
> After [SQOOP-2737] several users ran into that their SQOOP commands are
> failing due to the fact the original commands were not phrased cases
> sensitive table/column/schema names in mind.
> There had been also another outcome of this feature, that the "--split-by"
> option does not accept Oracle functions anymore (e.g. MOD(col_name,4) ), as
> after correct escaping+quoting it would be handled by Oracle as a db col
> name, instead of an expression to evaluate.
> My goal here is to introduce an option to turn on/off the (fully proper and
> industry standard) escaping implemented in [SQOOP-2737], and also add an
> environment variable support for that, thus users would have the backward
> compatible fallback plan, and not changing their command.
> I do also plan to implement an argument for supporting split-by with database
> functions/expressions, and thus the escaping and the split-by expressions
> features would become independent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
