[
https://issues.apache.org/jira/browse/SQOOP-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Veena Basavaraj updated SQOOP-1549:
-----------------------------------
Description:
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. 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}
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 ( that will mandate 3 classes) with specific
annotations for FromConfig, ToConfig and LinkConfig.
was:
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 Lin, but they still have to create
this dummy 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. 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}
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 ( that will mandate 3 classes) with specific
annotations for FromConfig, ToConfig and LinkConfig.
> 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
>
> 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. 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}
> 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 ( that will mandate 3 classes) with specific
> annotations for FromConfig, ToConfig and LinkConfig.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
