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

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

Github user jiang-wu commented on the issue:

    https://github.com/apache/drill/pull/1184
  
    @parthchandra Just to clarify on the JDBC comment.  What do you mean by 
"Json representation"? Do you instead mean the "Local[Date|Time]" class 
representation?  There are no "Json" being returned from the JDBC layer.  It 
uses Java collections Map or List objects.  Inside the Map | List, the change 
in this pull request properly uses objects of different classes: Local 
[Date|Time|DateTime] to represent the various date/time/timestamp values.
    
    So far so good.  Now, it is possible in the future, we may want to further 
translate the Local [Date|Time|DateTime] objects inside the Map|List to 
java.sql.[Date|Time|Timestamp] upon access.  But to do that inside the 
SqlAccessor, you would need to deep copy the Map|List and build another version 
with the date|time translated into java.sql.date|time.  That would seem like a 
lot of work for little gain. 
    
    I would say let's hold off on that for now.  A few databases seem to be 
moving toward using non-timezone based representation in JDBC if the database 
does not support timezones: 
https://jdbc.postgresql.org/documentation/head/8-date-time.html  It would make 
sense to consider changing the class used after deciding on what to do with 
Drill handling of timezones. 


> Output format for nested date, time, timestamp values in an object hierarchy
> ----------------------------------------------------------------------------
>
>                 Key: DRILL-6242
>                 URL: https://issues.apache.org/jira/browse/DRILL-6242
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Data Types
>    Affects Versions: 1.12.0
>            Reporter: Jiang Wu
>            Assignee: Jiang Wu
>            Priority: Major
>             Fix For: 1.14.0
>
>
> Some storages (mapr db, mongo db, etc.) have hierarchical objects that 
> contain nested fields of date, time, timestamp types.  When a query returns 
> these objects, the output format for the nested date, time, timestamp, are 
> showing the internal object (org.joda.time.DateTime), rather than the logical 
> data value.
> For example.  Suppose in MongoDB, we have a single object that looks like 
> this:
> {code:java}
> > db.test.findOne();
> {
>     "_id" : ObjectId("5aa8487d470dd39a635a12f5"),
>     "name" : "orange",
>     "context" : {
>         "date" : ISODate("2018-03-13T21:52:54.940Z"),
>         "user" : "jack"
>     }
> }
> {code}
> Then connect Drill to the above MongoDB storage, and run the following query 
> within Drill:
> {code:java}
> > select t.context.`date`, t.context from test t; 
> +--------+---------+ 
> | EXPR$0 | context | 
> +--------+---------+ 
> | 2018-03-13 | 
> {"date":{"dayOfYear":72,"year":2018,"dayOfMonth":13,"dayOfWeek":2,"era":1,"millisOfDay":78774940,"weekOfWeekyear":11,"weekyear":2018,"monthOfYear":3,"yearOfEra":2018,"yearOfCentury":18,"centuryOfEra":20,"millisOfSecond":940,"secondOfMinute":54,"secondOfDay":78774,"minuteOfHour":52,"minuteOfDay":1312,"hourOfDay":21,"zone":{"fixed":true,"id":"UTC"},"millis":1520977974940,"chronology":{"zone":{"fixed":true,"id":"UTC"}},"afterNow":false,"beforeNow":true,"equalNow":false},"user":"jack"}
>  |
> {code}
> We can see that from the above output, when the date field is retrieved as a 
> top level column, Drill outputs a logical date value.  But when the same 
> field is within an object hierarchy, Drill outputs the internal object used 
> to hold the date value.
> The expected output is the same display for whether the date field is shown 
> as a top level column or when it is within an object hierarchy:
> {code:java}
> > select t.context.`date`, t.context from test t; 
> +--------+---------+ 
> | EXPR$0 | context | 
> +--------+---------+ 
> | 2018-03-13 | {"date":"2018-03-13","user":"jack"} |
> {code}



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

Reply via email to