> On Apr 30, 2020, at 8:56 AM, Jon Pither <[email protected]> wrote:
>
> We went down the route of wrapping Calcite with our own JDBC driver that
> strips out the `VALIDTIME AS OF (...)` from ``VALIDTIME AS OF (...) SELECT
> * FROM FOO`. We do this by overriding CalcitePrepareImpl and adding
> internalParameters to the CalciteSignature, that our enumerator then uses
> when executing the actual query. Any feedback on this approach is welcome
> :-)
Overriding the prepare process with, say, a different parser or validator is a
bit messy but it sounds like you’re doing the right thing.
> Another question. Our underlying DB supports datetime fields, returning
> java.util.Dates back from queries for datetime columns. I'm thinking that
> we ought be able to map these Dates through to a column we define using
> SqlTypeName/TIMESTAMP. To get this to work though, our enumerator has to
> convert our dates into millis, for Calcite to then convert them back into
> java.util.Dates.. Feel like I missing something obvious to skip this
> conversion?
You should probably use java.sql.Date, java.sql.Timestamp etc. They are
sub-classes of java.util.Date but convey information about the semantics.
Our Enumerable convention decided to use Java long values (or java.lang.Long if
nullable) for SQL TIMESTAMP values, and int values for DATE and TIME values.
These are lighter weight than java.sql.Timestamp, and also make it less likely
to inadvertently do computations in the local time zone.
If the enumerator is just passing values through, then conversion to and from
might seem like significant effort. But sorry, it’s just how it is.
Julian
