[jira] [Comment Edited] (SQOOP-1551) Repository Upgrader api - Extensibility

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

    [ https://issues.apache.org/jira/browse/SQOOP-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160508#comment-14160508 ] 

Veena Basavaraj edited comment on SQOOP-1551 at 10/6/14 5:06 PM:
-----------------------------------------------------------------

Proposal


1. We should be more descriptive and not called it repository upgrader API, since repository upgrades are handled by the repository itself and not by the entities using it to store their data. 

eg code in one of the repository implementations we support
{code}
  * {@inheritDoc}
   */
  @Override
  public void createOrUpdateInternals(Connection conn) {
    int version = detectVersion(conn);

    if(version <= 0) {
      runQuery(QUERY_CREATE_SCHEMA_SQOOP, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_CONNECTOR, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_CONFIG, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_INPUT, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_LINK, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_JOB, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_LINK_INPUT, conn);
   
{code}

Today we have connector and driver that can provide configs key/ values( hence the name configurables)

I suggest we call this api config upgrader, other apt names are welcome. 

2. The current api we have is not extensible. Today we support do config types, LINK/ JOB ( since we think these config values are required to create a link / create a job. Tomm we can have other configs as well of different types, we can easily support this with a different annotation, like {code}@FooConfig {code}
So the config upgrader api should be generic to add this new type for upgrade as well.

{code}
//todo
{code}

3. The version field in configurable.( should be config_version)
It is mostly for config upgrade. So we might be more careful on what we call this. I suggest we call this config version, since that is all we need to track from these configurables.





was (Author: vybs):

Proposal


1. We should be more descriptive and not called it repository upgrader API, since repository upgrades are handled by the repository itself and not by the entities using it to store their data. 

eg code in one of the repository implementations we support
{code}
  * {@inheritDoc}
   */
  @Override
  public void createOrUpdateInternals(Connection conn) {
    int version = detectVersion(conn);

    if(version <= 0) {
      runQuery(QUERY_CREATE_SCHEMA_SQOOP, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_CONNECTOR, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_CONFIG, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_INPUT, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_LINK, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_JOB, conn);
      runQuery(QUERY_CREATE_TABLE_SQ_LINK_INPUT, conn);
   
{code}

Today we have connector and driver that can provide configs key/ values( hence the name configurables)

I suggest we call this api config upgrader, other apt names are welcome. 

2. The current api we have is not extensible. Today we support do config types, LINK/ JOB ( since we think these config values are required to create a link / create a job. Tomm we can have other configs as well of different types, we can easily support this with a different annotation, like {code}@FooConfig {code}
So the config upgrader api should be generic to add this new type for upgrade as well.





> Repository Upgrader api - Extensibility
> ---------------------------------------
>
>                 Key: SQOOP-1551
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1551
>             Project: Sqoop
>          Issue Type: Sub-task
>            Reporter: Veena Basavaraj
>            Assignee: Veena Basavaraj
>
> I am not sure if the current api is extensible enough. It only supports upgrading the config info. Which actually can be now done via the rest api as well. So do we really need this config upgrade api was my first thought?
> I am also not sure how this code supports upgrades across different versions, since there seems to be no code in any of these that has knowledge of the repository version and what type of repository it really belongs to
> Split the api into
> ConnectorConfigUpgrader
> upgradeLinkConfig
> upgradeFromJobConfig
> upgradeToJobConfig
> DriverConfig Upgrader
> upgradeDriverConfig



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