[
https://issues.apache.org/jira/browse/SQOOP-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224937#comment-14224937
]
Jarek Jarcec Cecho commented on SQOOP-1811:
-------------------------------------------
I feel that the name {{getCSVTextData()}} is a bit misleading as that is
suggesting that you can return any CSV format which is not the case. We've
locked the IDF into very strict subset of CSV and connectors are not allowed to
return arbitrary CSV. Hence I would prefer to keep the name {{getTextData()}}
with a comment that will explain that we're expecting our own format (that is
based on CSV).
In addition I don't think that we can make the method {{getTextData()}} final
as we don't know how to implement it. It's up to the IDF implementation to
convert the internal format to text and that is why this method is defined as
abstract.
Converting reusable functionality from the CSV IDF into reusable utils class is
completely fine.
> 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
>
> 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)
