[
https://issues.apache.org/jira/browse/SQOOP-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229262#comment-14229262
]
Veena Basavaraj commented on SQOOP-1811:
----------------------------------------
addressing your comments:
- we dont need text to be final, it must be a oversight that I typed in final
in the code sample above.
- setData or setObjectData should make sure the text is set if they support the
CSV-ish text, if they dont support it, then it is not necessary to set it. In
that case we can also have a method that isCSVStringSupported() and connectors
can check this before calling this method on any IDF implementation.
I am working on the AVRO IDF and I do see a need for this method, if the HDFS
TO connector uses this IDF, but wants to set the output to CSV or Avro based on
the output format requested in the JOB
- get* methods should not have any such responsibility
> 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)
