You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sqoop.apache.org by "Veena Basavaraj (JIRA)" <ji...@apache.org> on 2014/11/25 18:46:12 UTC

[jira] [Updated] (SQOOP-1811) IDF API changes

     [ https://issues.apache.org/jira/browse/SQOOP-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Veena Basavaraj updated SQOOP-1811:
-----------------------------------
    Description: 
1. update the java docs

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
 
  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

  was:
1. update the java docs

2.  Make the getTextData final and call it getCSV and setCSV, so it is obvious that we want to enforce CSV format

o me more concrete #1. the following code can move to the base class and made final, so there is no way to override this

// hold the string
 
  public final String getCSVTextData() {
    return text;
  }

 
  public final void setCSVTextData(String text) {
    this.text = text;
  }


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


> 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
> 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
>  
>   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)