sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abraham Elmahrek (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SQOOP-1061) Sqoop2: Introduce conditions on forms or inputs
Date Wed, 02 Jul 2014 23:48:25 GMT

     [ https://issues.apache.org/jira/browse/SQOOP-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Abraham Elmahrek updated SQOOP-1061:
------------------------------------

    Attachment: SQOOP-1061-Design.1.pdf

Placing conditions at the Form level rather than the Configuration object level in wire protocol.
Form names appear to be non-unique, so we are restricted to "same form" conditions for now.

> Sqoop2: Introduce conditions on forms or inputs
> -----------------------------------------------
>
>                 Key: SQOOP-1061
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1061
>             Project: Sqoop
>          Issue Type: New Feature
>    Affects Versions: 1.99.2
>            Reporter: Jarek Jarcec Cecho
>            Assignee: Abraham Elmahrek
>             Fix For: 2.0.0
>
>         Attachments: SQOOP-1061-Design.0.pdf, SQOOP-1061-Design.1.pdf
>
>
> Currently we have static set of forms for {{Connection}} and {{Job}} objects with all
possible inputs (~ questions) that we might possibly need to know. This seems to be very confusing
for the end user as he is asked questions that might not make sense for his case.
> For example consider the Generic JDBC Connector that is asking following questions when
creating the {{Job}} object:
> {code}
> Schema name:  (Make sense only for Table)
> Table name: (Make sense only for Table)
> Table SQL statement: (Make sense only for Query)
> Table column names:  (Make sense only for Table)
> {code}
> The possibilities {{Table name}} and {{Table SQL statement}} are mutually exclusive,
so can't be filled at the same time. We do have support for validations that will filter such
incorrect entries, however the user is still asked the questions, which is kind of confusing.
> I was thinking how to address this issue and I think that very nice and extensible solution
would be allow some sort of conditions on either forms or inputs (or maybe both). For example
we could create a new {{Enum}} input "Import type" with values {{TABLE}} or {{QUERY}} and
then create conditions on the individual inputs to show them up only in case that this new
input have certain value. For example (this is mock) for table:
> {code}
> Import Type:  TABLE
> Schema name: 
> Table name: 
> Table column names: 
> {code}
> Or for query:
> {code}
> Import Type:  QUERY
> Table SQL statement: 
> {code}
> I do not currently have more deeper proposal on my mind, however I'm looking forward
for community feedback to see if it would make sense to go with this proposal further. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message