[jira] [Updated] (SQOOP-1549) Simplifying the Configuration class concept in Connector api

["Veena Basavaraj (JIRA)" <ji...@apache.org>]

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

Veena Basavaraj updated SQOOP-1549:
-----------------------------------
    Fix Version/s: 1.99.5

> Simplifying the Configuration class concept in Connector api
> ------------------------------------------------------------
>
>                 Key: SQOOP-1549
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1549
>             Project: Sqoop
>          Issue Type: Sub-task
>            Reporter: Veena Basavaraj
>            Assignee: Veena Basavaraj
>             Fix For: 1.99.5
>
>
> Here is what happens today ( SQOOP-1367 ) when someone needs to write a connector.
> First they start looking at the connector api and sees that they need to implement configuration classes.  Well after some thinking they realize, they need 3 classes. Why they wonder? But they continue on and implement 3 classes. In some cases there is really nothing for Link Configuration, but they still have to create this dummy class for a Configuration Class and then another dummy one for config class, which if it were me would find it absurd. 
> Then after creating 3 configuration classes, they need to then create atleast 3 config classes. Note the use of word atleast.  The api is not at all obvious in telling them that they infact can create more than 3 config classes. It seems like a hidden feature unless until someone sees some sample code where there is more than one config class per configuration class. !!
> The naming "getJobConfigurationClass" tells them nothing. You may say javadoc could explain it, But I wonder why we need to even support 3 configuration classes and more than 3 config classes.
> {code}
>   /**
>    * @return Get link configuration class
>    */
>   public abstract Class getLinkConfigurationClass();
>   /**
>    * @return Get job configuration group per direction type or null if not supported
>    */
>   public abstract Class getJobConfigurationClass(Direction jobType);
> {code}
> Here is my proposal ( if at all you want to support groups of configs, they atleast name the class to "ConfiguratioGroup" 
> Here is how the apis makes it obvious, that this class can contain a group of link configs
> {code}
>   /**
>    * @return Get link configuration group class
>    */
>   public abstract Class getLinkConfigurationGroupClass();
>   /**
>    * @return Get job configuration group class per direction type or null if not supported
>    */
>   public abstract Class getJobConfigurationGroupClass(Direction jobType);
> {code}
> [~abec] seems to need some validation from the group on why it should be called "Group". I have explained my reasoning for this change in https://reviews.apache.org/r/26295/
> Alternatively I think the current design/ implementation to support config parameters grouping is overkill ( over designed) 
> I prefer simple apis, less things for a developer to code and intuitive names to everything they represent
> 1.  Remove the ConfigList and support grouping of configs by the "group" attribute on inputs
> 2.  Have one configuration class annotation  that will mandate 3 classes with specific annotations attributes on it FromConfig, ToConfig and LinkConfig to be filled. 
> So having one class, gives a complete picture of all configs this connector uses/ provides.  There is one resource bundle we require, so it maps to one configuration class as well. 
> In code this is how it will look
> {code}
>  */
> @ConfigurationGroupClass
> public class HdfsCongifuration {
>   @LinkConfig public LinkConfig linkConfig;
>   @FromConfig public FromJobConfig fromJobConfig;
>   @ToConfig public ToJobConfig toJobConfig;
>   
>  ....
> }
> {code}
> or
> {code}
> @ConfigurationGroupClass(link="LinkConfig.class", from="fromConfig.class", to="toConfig.class")
> public class HdfsCongifuration {
>  ....
> }
> {code}
> {code}
>  */
> @ConfigClass(validators = {@Validator(ToJobConfig.ConfigValidator.class)})
> public class ToJobConfig {
>   @Input(size = 50, group="foo")   public String schemaName;
>   @Input(size = 2000, group="bar") public String tableName;
>   @Input(size = 50)   public String sql;
>   @Input(size = 50)   public String columns;
>   @Input(size = 2000) public String stageTableName;
>   @Input              public Boolean clearStageTable;
>   
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)