Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Date: Sat, 17 Oct 2015 11:41:05 +0000 (UTC)
From: "Chesnay Schepler (JIRA)" <jira@apache.org>
To: issues@flink.apache.org
Message-ID: <JIRA.12875366.1442498415000.65705.1445082065015@Atlassian.JIRA>
In-Reply-To: <JIRA.12875366.1442498415000@Atlassian.JIRA>
References: <JIRA.12875366.1442498415000@Atlassian.JIRA>
 <JIRA.12875366.1442498415545@arcas>
Subject: [jira] [Commented] (FLINK-2692) Untangle CsvInputFormat into
 PojoTypeCsvInputFormat and TupleTypeCsvInputFormat
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Chesnay Schepler commented on FLINK-2692:
-----------------------------------------

ah my bad, its available through the Scala API's ExecutionEnvironment, so it's staying then...

> Untangle CsvInputFormat into PojoTypeCsvInputFormat and TupleTypeCsvInputFormat 
> --------------------------------------------------------------------------------
>
>                 Key: FLINK-2692
>                 URL: https://issues.apache.org/jira/browse/FLINK-2692
>             Project: Flink
>          Issue Type: Improvement
>            Reporter: Till Rohrmann
>            Assignee: Chesnay Schepler
>            Priority: Minor
>
> The {{CsvInputFormat}} currently allows to return values as a {{Tuple}} or a {{Pojo}} type. As a consequence, the processing logic, which has to work for both types, is overly complex. For example, the {{CsvInputFormat}} contains fields which are only used when a Pojo is returned. Moreover, the pojo field information are constructed by calling setter methods which have to be called in a very specific order, otherwise they fail. E.g. one first has to call {{setFieldTypes}} before calling {{setOrderOfPOJOFields}}, otherwise the number of fields might be different. Furthermore, some of the methods can only be called if the return type is a {{Pojo}} type, because they expect that a {{PojoTypeInfo}} is present.
> I think the {{CsvInputFormat}} should be refactored to make the code more easily maintainable. I propose to split it up into a {{PojoTypeCsvInputFormat}} and a {{TupleTypeCsvInputFormat}} which take all the required information via their constructors instead of using the {{setFields}} and {{setOrderOfPOJOFields}} approach.


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