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

ASF GitHub Bot commented on TAJO-1226:
--------------------------------------

Github user hyunsik commented on the pull request:

    https://github.com/apache/tajo/pull/301#issuecomment-68783286
  
    I had have thought of some design consideration. Our direction is to make 
storages pluggable. BTW, in this implementation, type validator is implemented 
separately from storage format implementation. Especially, type validator is in 
tajo-core. It would be better if validation and storage formation 
implementations are located in some same place.
    
    The way is to implement some class or interface to give file format 
properties. But, it causes some breaking changes and takes more time. So, I 
think that your patch is a nice approach right now. 
    
    Also, I'll create an issue to improve it to be on the our roadmap.


> LogicalPlanVerifier should check not supported type in file formats
> -------------------------------------------------------------------
>
>                 Key: TAJO-1226
>                 URL: https://issues.apache.org/jira/browse/TAJO-1226
>             Project: Tajo
>          Issue Type: Improvement
>          Components: planner/optimizer
>            Reporter: Hyunsik Choi
>            Assignee: DaeMyung Kang
>             Fix For: 0.10
>
>
> *Problem*
> There are a variety of file formats in Hadoop eco systems. BTW, they have 
> different type supports. For example, RCFile supports DATE type, but Parquet 
> does not support DATE. Users can use not supported data types in a specified 
> file format for writing tables.
> But, current Tajo does not check available data types for each file format. 
> So, if a user specifies not supported types in his table for writing, a 
> runtime error will occur while a query is running.
> *Solution*
> We should check not supported data type in logical plan verification phase.



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

Reply via email to