Mailing-List: contact dev-help@sqoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@sqoop.apache.org
Date: Mon, 1 Dec 2014 17:47:12 +0000 (UTC)
From: "Veena Basavaraj (JIRA)" <jira@apache.org>
To: dev@sqoop.apache.org
Message-ID: <JIRA.12757756.1416937448000.50279.1417456032917@Atlassian.JIRA>
In-Reply-To: <JIRA.12757756.1416937448000@Atlassian.JIRA>
References: <JIRA.12757756.1416937448000@Atlassian.JIRA>
 <JIRA.12757756.1416937448136@arcas>
Subject: [jira] [Commented] (SQOOP-1811) IDF API changes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Veena Basavaraj commented on SQOOP-1811:
----------------------------------------

Let me phrase  questions.

1. We have agreed to rename the API to getSqoopCSVData() and setSqoopCSVData(). I propose making this final and moving the text field to the base class (IDF).  My understanding was that every IDF implementation will have to provide this string.

Is that correct?

If the above is correct, then yes it is onus of the IDF implementation to use the SqoopCSVUtils and set the data in csv format and then the connectors will call the getSqoopCSVData(), we can assert that text is not nul at this point and if it is a exception will be thrown

2. getData() and getObjectData() even though I am not sure why both will be needed in all cases.  So in case of AvroIDF why would we need both.

getData() and setData() would set a Avro object that represents the row


> IDF API changes
> ---------------
>
>                 Key: SQOOP-1811
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1811
>             Project: Sqoop
>          Issue Type: Sub-task
>          Components: sqoop2-framework
>            Reporter: Veena Basavaraj
>             Fix For: 1.99.5
>
>
> 1. update the java docs for IDF apis.
> 2.  Make the getTextData final and call it getCSV and setCSV, so it is obvious that we want to enforce CSV format
>  the following code can move to the base class IntermediateDataFormat and made final, so there is no way to override this and we can enforce all to return String instead of generic T
> {code}
> // hold the string in IDF base class
>  private final String text.
>  
>   public final String getCSVTextData() {
>     return text;
>   }
>  
>   public final void setCSVTextData(String text) {
>     this.text = text;
>   }
> {code}
> There is code in CSVIDF implementation that has the rules for CSV parsing that can be pulled out into CSV Utils so that the connectors can use
> The T in CSV happens to String, which is just a coincidence, If I write a new IDF implementation T can be a custom object that could encapsulate the whole row.
> Third, getData and setData can have custom implementation so they can be overriden to return the generic type T


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