You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Chesnay Schepler (JIRA)" <ji...@apache.org> on 2015/11/18 21:44:11 UTC
[jira] [Closed] (FLINK-2692) Untangle CsvInputFormat into
PojoTypeCsvInputFormat and TupleTypeCsvInputFormat
[ https://issues.apache.org/jira/browse/FLINK-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chesnay Schepler closed FLINK-2692.
-----------------------------------
Resolution: Fixed
> 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)