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

ASF GitHub Bot commented on DRILL-6016:
---------------------------------------

Github user vdiravka commented on the issue:

    https://github.com/apache/drill/pull/1166
  
    @parthchandra I have compared meta of files from 
`TestParquetWriter.testImpalaParquetBinaryAsTimeStamp_DictChange` and the meta 
from Rahul's dataset and found that test case indeed makes a query from two 
parquet files: one is dictionary encoded and other isn't. But the dataMode of 
column is `Optional`, that's why `Nullable` column reader is used.
    Rahul's dataset contains `required` mode for INT96 column. This is a 
difference. Therefore other non-nullable column reader is necessary. 
    
    But I believe we have some mess in names of that column readers. Maybe to 
make some refactoring would be a good point. What do you think? For example to 
remove `Dictionary` prefixes from nested classes, but to leave it for top class 
name.


> Error reading INT96 created by Apache Spark
> -------------------------------------------
>
>                 Key: DRILL-6016
>                 URL: https://issues.apache.org/jira/browse/DRILL-6016
>             Project: Apache Drill
>          Issue Type: Bug
>         Environment: Drill 1.11
>            Reporter: Rahul Raj
>            Priority: Major
>             Fix For: 1.14.0
>
>
> Hi,
> I am getting the error - SYSTEM ERROR : ClassCastException: 
> org.apache.drill.exec.vector.TimeStampVector cannot be cast to 
> org.apache.drill.exec.vector.VariableWidthVector while trying to read a spark 
> INT96 datetime field on Drill 1.11 in spite of setting the property 
> store.parquet.reader.int96_as_timestamp to  true.
> I believe this was fixed in drill 
> 1.10(https://issues.apache.org/jira/browse/DRILL-4373). What could be wrong.
> I have attached the dataset at 
> https://github.com/rajrahul/files/blob/master/result.tar.gz



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to