[
https://issues.apache.org/jira/browse/SQOOP-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113025#comment-13113025
]
Ken Krugler commented on SQOOP-350:
-----------------------------------
Yes, thanks for pointing that out - I thought this was a way to change the
Sqoop connection manager, not the pluggable connection being used.
I tried it out, and using --connection-manager
com.quest.oraoop.OraOopManagerFactory forced OraOop to be used. If OraOop tried
to hand off responsibility (because it decided it couldn't handle the request)
then the Sqoop failed, which is exactly the behavior that we need.
It would be great to call this out in the documentation, maybe with a note that
the class will (typically be) xxx.YyyManagerFactory, since it took a few tries
for me to figure out that the right class name is the factory, not the actual
manager.
> Add support for requiring that a connector be used, otherwise the job should
> fail
> ---------------------------------------------------------------------------------
>
> Key: SQOOP-350
> URL: https://issues.apache.org/jira/browse/SQOOP-350
> Project: Sqoop
> Issue Type: Improvement
> Components: connectors
> Affects Versions: 1.3.0
> Reporter: Ken Krugler
>
> There are situations where it is critical that a specific connector be used
> during a Sqoop. For example, if you have a table that doesn't have a suitable
> column for partitioning, and thus you're relying on OraOop's row-based
> partitioning, then it's critical that OraOop be used. If the Sqoop request
> falls back to the generic Oracle connector, this puts huge, unacceptable load
> on the database.
> The proposal is to add a -connector <class name> parameter, which will cause
> the job to fail unless it's handled by the connector (from
> sqoop.ConnFactory.getManager) with the matching class name.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
