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

Ivan Mushketyk commented on FLINK-5280:
---------------------------------------

Hi [~fhueske]

{quote}
We could have default implementations for {{getFieldNames()}} and 
{{getFieldIndicies()}} that return null and use 
{{TableEnvironment.getFieldInfo(TypeInformation)}} or the explicitly provided 
information if the methods are overridden. That would allow us to reuse 
existing code instead of duplicating it.
{quote}

I think this is not very object-oriented way of doing it. IMO it would be 
better to provide a default implementations of  {{getFieldNames()}} and 
{{getFieldIndicies()}}, but let a user to override these methods. This seems to 
be a cleaner approach.

{quote}
I think getFieldTypes() and getNumberOfFields() are truly redundant and might 
even cause problems if they are not consistent with getReturnType(). 
{quote}

These methods are used in current flink-table code base and we need to 
implement them somewhere. So the question is where to put them. We can put them 
in a Util class of some sort to avoid duplication or we can put them into 
{{TableSource}} class and make them final to ensure that they are consistent 
with {{getFieldNames()}} and {{getFieldIndicies()}} and type information. I am 
not married to the idea of keeping them in {{TableSource}} but it seems to be a 
bit cleaner to keep them in a Util class.

So I would propose some combination of my previous idea and Fabian's idea:

* Add {{getFieldIndicies}} method
* Add default implementations for {{getFieldNames}} add {{getFieldIndicies}} 
based on {{getReturnType()}}, but make them overridable
* Add default implementations for {{getFieldTypes()}} and 
{{getNumberOfFields()}}, but make them final
* Leave {{getReturnType()}} unimplemented in trait. This will be the only 
method a user need to implement in the simplest case

What do you think [~fhueske], [~jark]

> 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)

Reply via email to