sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Veena Basavaraj (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SQOOP-1551) Repository Upgrader api - Extensibility
Date Mon, 06 Oct 2014 17:04:33 GMT

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

Veena Basavaraj commented on SQOOP-1551:


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

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

    if(version <= 0) {
      runQuery(QUERY_CREATE_SCHEMA_SQOOP, 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);

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

View raw message