Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Date: Thu, 15 Dec 2016 03:39:59 +0000 (UTC)
From: "Jark Wu (JIRA)" <jira@apache.org>
To: issues@flink.apache.org
Message-ID: <JIRA.13026412.1481132455000.526126.1481773199048@Atlassian.JIRA>
In-Reply-To: <JIRA.13026412.1481132455000@Atlassian.JIRA>
References: <JIRA.13026412.1481132455000@Atlassian.JIRA> <JIRA.13026412.1481132455884@arcas>
Subject: [jira] [Commented] (FLINK-5280) Extend TableSource to support
 nested data
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 15 Dec 2016 03:40:01 -0000


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

Jark Wu commented on FLINK-5280:
--------------------------------

Hi [~ivan.mushketyk], thanks for your detailed and clear proposal. 

Regarding to the new argument {{fieldMappings}} in {{FlinkTable}}, I think it is playing the same role  of {{fieldIndexes}}. Actually, {{fieldIndexes}} is the {{inputPojoFieldMapping}} in {{CodeGenerator}} when converting. In case of POJO, {{fieldIndexes}} is a fieldMapping. In other cases, it is an array of {{0~n}}.

Regarding to the {{getNumberOfFields}} in {{TableSource}}, yes, it is used rarely used and can be  replaced by {{getFieldsNames.length}} if {{getFieldsNames}} still display the first level attributes.

Hi [~fhueske], I agree with the {{RowTypeInfo}} approach which is similar to Calcite's way I think. But we should support custom names in {{RowTypeInfo}} first. 

> Extend TableSource to support nested data
> -----------------------------------------
>
>                 Key: FLINK-5280
>                 URL: https://issues.apache.org/jira/browse/FLINK-5280
>             Project: Flink
>          Issue Type: Improvement
>          Components: Table API & SQL
>    Affects Versions: 1.2.0
>            Reporter: Fabian Hueske
>            Assignee: Ivan Mushketyk
>
> The {{TableSource}} interface does currently only support the definition of flat rows. 
> However, there are several storage formats for nested data that should be supported such as Avro, Json, Parquet, and Orc. The Table API and SQL can also natively handle nested rows.
> The {{TableSource}} interface and the code to register table sources in Calcite's schema need to be extended to support nested data.


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