phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: TIME/DATE/TIMESTAMP questions
Date Thu, 02 Jul 2015 17:15:17 GMT
Hi Lukas,

I cannot answer all of your questions, but let me try one what I can.

Even stranger is how the query server handles the types. It only accepts
> the formatted string or to_time/to_date function on it, but always outputs
> a number, which is the number of milliseconds since 00:00:00.000 for TIME
> and days since 1970-01-01 for DATE. So while you are forced to enter the
> full date/time on input, and it's also stored as such, you only get a part
> of it on output. Is the asymmetry intended? I'd have expected to have the
> same type on both input and output.
>

This sounds like a "quirk" :) Your earlier comments about Phoenix's
non-standard handling of these types are probably conflicting with
Calcite's implementation, based on stated standard. Or maybe it's just
another bug. Either way, I think it's not intended.

The remote JDBC driver also crashes when fetching TIME/TIMESTAMP values
> (CALCITE-779), but that's definitely a bug. :)
>

*nod*

Another possible problem is that when parsing date/time values, the code
> raises java.lang.IllegalArgumentException instead of a "data error"
> java.sql.SQLException, so it has to be handled as "internal error" on the
> client, not a proper SQL exception.
>

Please file a Phoenix bug for this.

I guess the main question is what is the expected behavior for
> TIME/DATE/TIMESTAMP on all levels, internally in HBase, in the native JDBC
> driver and over the Avarica RPC?
>

The expectation of Avatica RPC is that is is a transparent pass-through
layer. Using the query server should not impact the semantics of any query
or its results.

Mime
View raw message