The Apache Jenkins build system has built Calcite-Master (build #1263)
Status: Failure
Check console output at https://builds.apache.org/job/Calcite-Master/1263/ to
view the results.
Hello Calcite Team,
I have a requirement to query multiple data sources in single SQL query, I
saw Calcite was providing this with JDBC adaptor, So while running I found
some challenges like,
1. This execution was happening in the memory that will cause OOM when
big data execution.
2.
Hi all,
I have a question regarding the usage & implementation of SqlFunctions.
internalToTimestamp(long v) (I copied the implementation below). I want to
clarify the definition of input parameter v. Is it milliseconds since
epoch, or something else?
If it is milliseconds since epoch, why do we n
Here's an update: Gradle-based build seems to be in a quite a good shape.
Just in case: it builds source artifacts (in zip and tgz formats), it
assembles licenses, it runs tests.
The missing bit is /docker/pom.xml -- I have no idea what it does.
Any feedback?
Vladimir
Before we accept this, I would like to make sure that the source
artifacts are identical (in terms of name, contents, internal
directory structure) to the artifacts we produce today, and the same
goes for the contents of the JAR files (manifests,
META-INF/service/java.sql.Driver files) and generate
Note that that function is for a specialized purpose: converting internal
timestamps to java.sql.Timestamp objects to be passed as arguments to
user-defined functions implemented in Java.
It assumes that the SQL timestamp values are in the JVM’s default time zone,
and since are converting to ja
Thanks a lot for the quick response, Julian! So if I understand your answer
correctly, the input parameter *v* of internalToTimestamp() is NOT
milliseconds since epoch, and is defined as milliseconds since epoch +
LOCAL_TZ.getOffset(). And if we have a timestamp long value that are
milliseconds si
