[ https://issues.apache.org/jira/browse/SQOOP-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Veena Basavaraj updated SQOOP-1596:
-----------------------------------
Description:
{code}
package org.apache.sqoop.common;
/**
* Defines an error-code contract. Sqoop exceptions use the error code to
* communicate error information where possible. Each error code is associated
* with default message that identifies the high level information related to
* the underlying error condition.
*/
public interface ErrorCode {
/**
* @return the string representation of the error code.
*/
String getCode();
/**
* @return the message associated with error code.
*/
String getMessage();
}
{code}
to
{code}
package org.apache.sqoop.common;
/**
* Defines an error-code contract. Sqoop exceptions use the error code to
* communicate error information where possible. Each error code is associated
* with default message that identifies the high level information related to
* the underlying error condition.
*/
public abstract class ErrorCode {
/**
* @return the string representation of the error code.
*/
String getCode() {
}
/**
* @return the message associated with error code.
*/
String getMessage() {
}
}
{code}
was:
SQ_CONNECTOR -> will be now call SQ_CONFIGURABLE ( it is basically a table to hold entities
that will specify configs)
Add another field to it, that is CONFIGURABLE_TYPE ( it can be connector or driver at this
point ). we can have a standard id for Driver that we will use in the SQOOP, having nulls
to represent things is not clean since "none/null" can mean different things at different
contexts
Most importantly, not to have NULLs representing one too many things!!
Next,
We propose to split up the SQ_FORM ( which is the SQ_CONFIG after 1498) to SQ_JOB_CONFIG and
SQ_LINK_CONFIG ( it will parallel the SQ_JOB_INPUT and SQ_LINK_INPUT)
Direction is only relevant to job config ( and henceforth the job inputs). So we will store
the DIRECTION field in JOB_CONFIG.
If we want to have SQ_CONFIG, we can have it with the SQ_CFG_TYPE and then it will have FK
on the SQ_CONFIGURABLE, so we know which entity owns this config easily.
We can then have SQ_JOB_CONFIG and SQ_LINK_CONFIG have a FK on SQ_CONFIG.
Alternatively, dont have SQ_CONFIG, and just have SQ_JOB_CONFIG and SQ_LINK_CONFIG and have
a FK directly to SQ_CONFIGURABLE, both will have the CONFIG_NAME and INDEX fields.
Last,
MIsc cleanup/ renames / documentation of the repository schema query names for clarity and
consistency. Especially the create schema / upgrade schema and then CRUD queries are groupes
apts.
> Sqoop2: Make ErrorCode a base class ( avoid repeated code in every connector)
> -----------------------------------------------------------------------------
>
> Key: SQOOP-1596
> URL: https://issues.apache.org/jira/browse/SQOOP-1596
> Project: Sqoop
> Issue Type: Improvement
> Reporter: Veena Basavaraj
> Assignee: Veena Basavaraj
>
> {code}
> package org.apache.sqoop.common;
> /**
> * Defines an error-code contract. Sqoop exceptions use the error code to
> * communicate error information where possible. Each error code is associated
> * with default message that identifies the high level information related to
> * the underlying error condition.
> */
> public interface ErrorCode {
> /**
> * @return the string representation of the error code.
> */
> String getCode();
> /**
> * @return the message associated with error code.
> */
> String getMessage();
> }
> {code}
> to
> {code}
> package org.apache.sqoop.common;
> /**
> * Defines an error-code contract. Sqoop exceptions use the error code to
> * communicate error information where possible. Each error code is associated
> * with default message that identifies the high level information related to
> * the underlying error condition.
> */
> public abstract class ErrorCode {
> /**
> * @return the string representation of the error code.
> */
> String getCode() {
> }
> /**
> * @return the message associated with error code.
> */
> String getMessage() {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
|